- Boost - lists.boost.org

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

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

17 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-16T14:08:08Z 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… 3 failures in 3 libraries: multi_index (1) serialization (1) thread (1) |multi_index| test_conv_iterators: vc-8_0 |serialization| test_multiple_ptrs_binary_archive: vc-8_0 |thread| test_mutex_lib: tru64cxx71-006

3 2