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

asio networking proposal 0.3.5
by Christopher Kohlhoff 18 Nov '05

18 Nov '05

Hello all, I have just released asio 0.3.5. You can download it, or view the documentation online, at http://asio.sourceforge.net. The download page includes packages named boost-asio-proposal-*, which contain a version of asio converted into boost format. You can copy the contents of one of these into a boost_1_33_0 distribution and build it there, but it should also support building in its own directory, provided you set a BOOST_ROOT environment variable. The Jamfiles are a little rough, but they should work in theory. The size of the release is actually less than 0.3.4, which I think is a good sign :) In detail, the changes since asio 0.3.4 include: - Consolidated the free functions read(), read_n() and read_at_least_n() into a function named read(); write(), write_n() and write_at_least_n() into just write(); and likewise for their asynchronous counterparts. The default behaviour of read() and write() is now to attempt to transfer all of the data (i.e. equivalent to old read_n() and write_n()). The _at_least_n() behaviour can be obtained by passing a Completion_Condition function object: asio::read(s, bufs, asio::transfer_at_least(32)); - Renamed the Stream concept's read(), async_read(), write() and async_write() functions to read_some(), async_read_some(), write_some() and async_write_some() respectively. This was done to make it obvious to a library user that the operation can result in a short read or write. The name write() in particular was found to be error prone, since most of the time it will successfully transfer all of the data. Only occasional calls would result in a short write, leading to hard to find bugs. - Graceful connection closure now causes a read to complete with an error code (asio::error::eof) rather than returning 0. This removes the need for separate total_bytes_transferred and last_bytes_transferred handler parameters. It allows a function, such as asio::read() and asio::write(), to return an error to indicate that it is unable to fulfil its contract due to EOF. - Removed the asio::buffers() function and the ability to automatically chain buffer objects together. Instead, the asio::buffer() function now returns a type that meets the Const_Buffers or Mutable_Buffers concepts as appropriate. Scatter-gather I/O should now be performed by explicitly placing const_buffer or mutable_buffer objects into a container (such as std::vector, std::list or boost::array). To read into a single buffer you would now write: sock.read(asio::buffer(data, length)); To send multiple buffers you would use something like: std::vector<asio::const_buffer> bufs; bufs.push_back(asio::buffer(data1, length1)); bufs.push_back(asio::buffer(data2, length2)); sock.write(bufs); - Added comparison operators to the asio::ipv4::tcp::endpoint and asio::ipv4::udp::endpoint classes. - Removed the error handling expression templates. This functionality is better covered by a library such as Boost.Lambda. - Removed the fixed_buffer class from the library's public interface. The underlying buffer storage is no longer a template parameter on the buffered*_stream classes. - Removed the wrapped_handler class from the library's public interface. - Removed the consuming_buffers class from the libary's public interface. - Added new certificates for the SSL example, as the original ones expired after one month. - Used implementation-defined types rather than void* in the Socket_Option and IO_Control_Command concepts to avoid losing type safety. - Various code cleanup and bug fixes. - Added support for MSVC 8.0. - Documentation improvements. Cheers, Chris

1 0

Help setting up boost for vc7
by Marcelo Juchem 18 Nov '05

18 Nov '05

Hi, I had some problems when trying to build boost-jam under WinXP SP2 with MSVC7.1. I searched the boost mailing list and found this message: "I have MS VC++ 7.1 installed to the default location (C:\Program Files\Microsoft Visual Studio .NET 2003), O/S WinXPSP2 However, when I run Build.bat from the command line, it returns " \Utilities\Bin\x86 was unexpected at this time." This occurs if I let the script auto-detect and also if I specify the toolset as vc7. Can someone please steer me in the right direction? regards Chris Ward" By debbuging the build.bat script, I could figure out what the problem is. It seems to be a problem with PATH environment variables that contains parenthesis '(' or ')'. This is the PATH I had when the problem occurred: "PATH=C:\Program Files\Microsoft DirectX 9.0 SDK (October 2005)\Utilities\Bin\x86;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\cygwin\bin;C:\Program Files\Common Files\GTK\2.0\bin;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin" Just by removing "C:\Program Files\Microsoft DirectX 9.0 SDK (October 2005)", the build.bat script started working perfectly. This is caused because all the variables are expanded inline in a .bat file, so the parenthesis are understood as scope delimiters and messes up with the if () statements as in: if not "_%BOOST_JAM_TOOLSET_ROOT%_" == "__" ( set PATH=%BOOST_JAM_TOOLSET_ROOT%Other Metrowerks Tools\Command Line Tools;%PATH%) This code is expanded as if not "_%BOOST_JAM_TOOLSET_ROOT%_" == "__" ( set PATH=c:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\\..\..\VC7\Other Metrowerks Tools\Command Line Tools;C:\Program Files\Microsoft DirectX 9.0 SDK (October 2005)\Utilities\Bin\x86;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\cygwin\bin;C:\Program Files\Common Files\GTK\2.0\bin;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin) what leaves the script broken. I hope I could be able to make myself clear when trying to explain this. A quick workaround is to remove paths that contains parenthesis from the PATH environment variable, before running the script. Thanks, Marcelo Juchem

1 0

help naming new library (math / computer science experts needed)
by Eric Niebler 18 Nov '05

18 Nov '05

I am working on a new library. It is a computational framework where the computations follow the following pattern: - Users build a computational object by selecting the computations they are interested in (or author their own computational primimtives which fit within the framework). - Users push data into the object one sample at a time - The object computes the requested quantities in the most efficient method possible (resolving dependencies between requested calculations, cacheing intermediate results, etc.) - The object may or may not be stateful. What should such a library be called? Is there an accepted term for such a computational model? -- Eric Niebler Boost Consulting www.boost-consulting.com

6 5

Re: [boost] [parameter] - catching accidental duplicate parameters at compile time
by Daniel Earwicker 18 Nov '05

18 Nov '05

David Abrahams: > On conforming compilers, the library uses overloading to look up the > value associated with any given keyword. I assumed that having two of > the same keyword would cause an ambiguity error at lookup time: 7.3.3/12 of the standard appears to deal with this: "When a using-declaration brings names from a base class into a derived class scope, member functions in the derived class override and/or hide member functions with the same name and parameter types in a base-class (rather than conflicting)." i.e. a working model of the same keyword twice on an arg_list: struct keyword {}; struct base { int operator[](const keyword &) { return 1; } }; struct derived : public base { using base::operator[]; int operator[](const keyword &) { return 2; } }; int main() { return derived()[keyword()]; } > The problem with this (aside from the use of an ALL_CAPS name for > something other than a macro) Thanks for the tip! > is that it costs O(N^2) instantiations, > where N is the number of arguments. OTOH you could do it with > overloading (or just use an mpl::set, which uses overloading > internally) to do it in O(N). Oooh, that's much better. With used_keywords as an empty set in empty_arg_list, all it needs in arg_list is: BOOST_STATIC_ASSERT((!boost::mpl::has_key< typename Next::used_keywords, key_type>::type::value)); typedef typename mpl::insert<typename Next::used_keywords, key_type>::type used_keywords; Or is there already something that captures the above pattern, i.e. refuses to insert a duplicate? --Daniel.

3 9

[Boost-bugs] [ boost-Bugs-1359257 ] [variant] Bug in recursive_wrapper_fwd.hpp
by SourceForge.net 17 Nov '05

17 Nov '05

Bugs item #1359257, was opened at 2005-11-17 12:13 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=1359257&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: [variant] Bug in recursive_wrapper_fwd.hpp Initial Comment: I've been tracking down an preprocessor warning involving the redefinition of BOOST_TT_AUX_BOOL_TRAIT_DEF1. It appears to me that variant/recursive_wrapper_fwd.hpp is misusing: #include "boost/type_traits/detail/bool_trait_def.hpp" The usual include pattern for this header is: // should be the last #include #include "boost/type_traits/detail/bool_trait_def.hpp" ... #include "boost/type_traits/detail/bool_trait_undef.hpp" But recursive_wrapper_fwd.hpp has: #include "boost/type_traits/detail/bool_trait_def.hpp" #include "boost/mpl/aux_/lambda_support.hpp" ... and no include for bool_trait_undef.hpp. This is causing a redefinition warning on Apple darwin for BOOST_TT_AUX_BOOL_TRAIT_DEF1. Changing recursive_wrapper_fwd.hpp to the usual use pattern of bool_trait_def.hpp as described above silences the warning. Thanks, Howard hinnant(a)twcny.rr.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1359257&group_… ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Test] BOOST_CHECK_CLOSE Feature request
by John Maddock 17 Nov '05

17 Nov '05

I have a couple of feature requests for Boost.Test: 1) Can BOOST_CHECK_CLOSE please print the actual difference between the values (as a percent to match the tolerance) as well as the values themselves? The reason this is important, is that it's not always easy to get this value from the input values - because the precision of the machine on which the test is run far outstrips that of the author's machine, so his calculator isn't any use :-( 2) Can we please have a BOOST_CHECK_EPSILON, that uses a whole number of epsilon as the tolerance? IMO BOOST_CHECK_CLOSE should have been written this way to begin with, but it's too late now. Again it should print out the actual relative error as a multiple of epsilon as well as the input values. Actually while we're at it the absolute error may be useful to have in some situations as well :-) BTW, in case it helps: I've switched to using std::pow(two, 1-std::numeric_limits<T>::digits) to calculate machine epsilon, because of the strange behaviour on Darwin with long doubles if you use numeric_limits<>::epsilon() (see http://lists.boost.org/Archives/boost/2005/09/93390.php) Thanks! John.

6 13

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

17 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-17T14:40:15Z 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… 2 failures in 2 libraries: multi_index (1) serialization (1) |multi_index| test_conv_iterators: vc-8_0 |serialization| test_multiple_ptrs_binary_archive: vc-8_0

2 1

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

17 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-17T06:00:17Z 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… 141 failures in 13 libraries: concept_check (12) date_time (2) graph (2) io (1) math (2) mpl (1) parameter (12) serialization (34) spirit (2) tr1 (49) type_traits (1) typeof (18) xpressive (5) |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 |date_time| testwcustom_time_zone: mingw-3_4_2 testwposix_time_zone: mingw-3_4_2 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |math| complex_test: gcc-3_4_3-sunos log1p_expm1_test: gcc-3_4_3-sunos |mpl| size_t: gcc-4_0-darwin |parameter| basics: 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 macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tutorial: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |serialization| test_array_text_warchive_dll: vc-7_1 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 test_demo_auto_ptr: vc-7_1 test_demo_auto_ptr_dll: vc-7_1 test_demo_dll: vc-7_1 |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |tr1| run_complex_overloads: gcc-2.95.3-linux gcc-3_4_3-sunos std_run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3_4_3-sunos std_run_random: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_boost: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_complex: gcc-2.95.3-linux std_test_hash: gcc-2.95.3-linux std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux std_test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux 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_algorithm: gcc-2.95.3-stlport-4.6.2-linux test_complex: gcc-2.95.3-linux test_exception: gcc-2.95.3-stlport-4.6.2-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_new: gcc-2.95.3-stlport-4.6.2-linux test_ostream: gcc-2.95.3-linux test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux 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 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-darwin test_utility: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tr1_has_virtual_destructor_test: intel-win32-9_0 |type_traits| has_virtual_destructor_test: intel-win32-9_0 |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| test3u: gcc-3_3-darwin test4u: gcc-3_3-darwin test5u: gcc-3_3-darwin test6u: gcc-3_3-darwin test9u: gcc-3_3-darwin

1 0

[Review] Boost.Logging review result
by Hartmut Kaiser 17 Nov '05

17 Nov '05

Hi all, today I got the following message from John Torjo: <quote> Due to the feedback I got, I would like you to declare the library as rejected. In the light of what Gennady and others have said, indeed, another interface would be best suited for the Boost Log library. With what I know now, I would like to redesign the library from ground up, and ask for another review, probably 6 months from now or so. </quote> In the light of this announcement the review of the proposed Boost.Logging library submitted by John is closed. The library is not included into Boost. I very much hope John will find the time and energy to redesign and resubmit the library in the future. Regards Hartmut Review Manager

4 4

Re: [boost] mpl help needed - doing the impossible?
by Martin Bonner 17 Nov '05

17 Nov '05

----Original Message---- From: Manfred Doudar [mailto:manfred.doudar@metoceanengineers.com] Sent: 16 November 2005 11:35 To: boost(a)lists.boost.org Subject: Re: [boost] mpl help needed - doing the impossible? > Manfred Doudar wrote: > >> >> /* Now, how do I get T out when Rank == 1, ... compiler complains >> about seeing a MyArray/blitz::Array of <T, Rank = 0> >> (, which is not defined for blitz Arrays) >> */ >> template <typename T, int Rank> >> typename boost::mpl::if_ >> < typename boost::mpl::equal_to >> < boost::mpl::int_<Rank> >> , boost::mpl::int_<1> >> >::type >> , T >> , blitz::Array<T, >> >> boost::mpl::int_<Rank>::prior::value> >> >> > > ^ > Oops typo, should be: > MyArray<T, > > boost::mpl::int_<Rank>::prior::value> > > ... but nonetheless, the problem remains ... > >> >::type >> MyArray<T, Rank> :: operator[] (const int& index) throw(); { >> // Slicing How about a helper traits class? template <typename T, int Rank> struct SliceType { typedef typename MyArray<T, Rank-1> type; }; template <typename T> struct SliceType<T,1> { typedef T type; }; template <typename T, int Rank> typename SliceType<T,Rank>::type MyArray<T,Rank> :: operator[] (const int& index) throw(); -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 5