August 2004 - Boost - lists.boost.org

RE: [boost] [boost.test] Patch for true64cxx65 support.
by Rozental, Gennadiy 17 Aug '04

17 Aug '04

> Hello, > > attached is a patch which makes boost.test work for the > beforementioned > toolset. It contains a workaround for the internal compiler > error currently > preventing any tests from running. Could anyone please apply > it, if it's ok? > > Thanks, Markus Why do you need anything more then: +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590041)) +typedef const_string literal_string; +#else typedef const_string const literal_string; +#endif Gennadiy

2 1

Fw: Rational Discovery LLC Copyrights?
by John Maddock 17 Aug '04

17 Aug '04

Another permission for our records: ----- Original Message ----- From: "Greg Landrum" <Landrum(a)RationalDiscovery.com> To: "David Abrahams" <dave(a)boost-consulting.com>; "John Maddock" <john(a)johnmaddock.co.uk> Sent: Monday, August 16, 2004 3:37 PM Subject: Re: Rational Discovery LLC Copyrights? > At 07:14 AM 8/16/2004, David Abrahams wrote: > >"John Maddock" <john(a)johnmaddock.co.uk> writes: > > > > > Dave, > > > > > > I see that you committed two files copyright "Rational Discovery LLC" > > > (libs/python/test/crossmod_exception_a.cpp > > > libs/python/test/crossmod_exception_b.cpp). Do you know who we need to > > > contact to get permission to change these to the BSL? > > > >These are Greg Landrum's. I am not certain how to reach him, but I > >Cc'd all the likely emails I could find. > > Feel free to change the copyright/license statements as is necessary. > > Best Regards, > Greg Landrum > President > Rational Discovery LLC > > >

3 4

RE: [boost] Re: ETI bug and iterators
by Yitzhak Sapir 17 Aug '04

17 Aug '04

> -----Original Message----- > From: David Abrahams > > "Yitzhak Sapir" <yitzhak.sapir(a)actimize.com> writes: > > > Hello. > > > > I am in the process of upgrading code to use boost 1.31.0 > for MSVC6.5. > > During this process I happened upon minimum_category.hpp which > > contains "ETI workarounds". Now, it seems that the ETI workarounds > > cause the compilation to fail, with the error message: constant > > expression expected. Particularly, we are creating zip iterators to > > two STLPort vectors. In debug iterator mode, I get the following > > error. (minimum_category.hpp was modified a bit > > Post the error you get with an unmodified minimum_category.hpp, > please. It's hard to analyze when the line numbers are wrong. > ../../3rdParty\boost/iterator/detail/minimum_category.hpp(86) : error C2039: 'apply' : is not a member of '?$minimum_category_impl@$$00' ../../3rdParty\boost/iterator/detail/minimum_category.hpp(97) : see reference to class template instantiation 'boost::detail::minimum_category<struct boost::random_access_traversal_tag,struct boost::random_access_traversal_tag>' being compil ed ../../3rdParty\boost/mpl/aux_/preprocessed/msvc60/apply.hpp(88) : see reference to class template instantiation 'boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >::apply<struct boost::random_access_travers al_tag,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/mpl/aux_/preprocessed/msvc60/apply.hpp(101) : see reference to class template instantiation 'boost::mpl::aux::msvc_apply2<struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> > >::re sult_<struct boost::random_access_traversal_tag,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/iterator/zip_iterator.hpp(173) : see reference to class template instantiation 'boost::mpl::apply2<struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >,struct boost::random_access_ traversal_tag,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/mpl/aux_/preprocessed/msvc60/apply.hpp(9) : see reference to class template instantiation 'boost::detail::tuple_impl_specific::tuple_meta_accumulate_impl<struct boost::tuples::cons<struct boost::random_access_traversal_t ag,struct boost::tuples::null_type>,struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/mpl/apply_if.hpp(39) : see reference to class template instantiation 'boost::mpl::apply0<struct boost::detail::tuple_impl_specific::tuple_meta_accumulate_impl<struct boost::tuples::cons<struct boost::random_access_traver sal_tag,struct boost::tuples::null_type>,struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >,struct boost::random_access_traversal_tag> >' being compiled ../../3rdParty\boost/iterator/zip_iterator.hpp(198) : see reference to class template instantiation 'boost::mpl::apply_if<struct boost::mpl::or_<struct boost::is_same<struct boost::tuples::cons<struct boost::random_access_traversal_tag,struc t boost::tuples::null_type>,struct boost::tuples::null_type>,struct boost::is_same<struct boost::tuples::cons<struct boost::random_access_traversal_tag,struct boost::tuples::null_type>,int>,struct boost::mpl::bool_<0>,struct boost::mpl::bool_<0>,str uct boost::mpl::bool_<0> >,struct boost::mpl::identity<struct boost::random_access_traversal_tag>,struct boost::detail::tuple_impl_specific::tuple_meta_accumulate_impl<struct boost::tuples::cons<struct boost::random_access_traversal_tag,struct boost ::tuples::null_type>,struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >,struct boost::random_access_traversal_tag> >' being compiled > > but the problem is > > in the instantiation of boost::is_same<T1 or T2,int>). > ^^^^^^^^ > > Huh? That's not valid regardless of any ETI workarounds. > That was my attempt to shorthand "either boost::is_same<T1,int> or boost::is_same<T2,int>"

2 1

[boost.test] Patch for true64cxx65 support.
by Markus Schöpflin 17 Aug '04

17 Aug '04

Hello, attached is a patch which makes boost.test work for the beforementioned toolset. It contains a workaround for the internal compiler error currently preventing any tests from running. Could anyone please apply it, if it's ok? Thanks, Markus diff -ru boost-04-08-17-0400/boost/test/detail/basic_cstring/basic_cstring_fwd.hpp boost-cvs/boost/test/detail/basic_cstring/basic_cstring_fwd.hpp --- boost-04-08-17-0400/boost/test/detail/basic_cstring/basic_cstring_fwd.hpp 2004-07-19 14:28:17.000000000 +0200 +++ boost-cvs/boost/test/detail/basic_cstring/basic_cstring_fwd.hpp 2004-08-17 17:39:02.000000000 +0200 @@ -16,13 +16,21 @@ #ifndef BASIC_CSTRING_FWD_HPP_071894GER #define BASIC_CSTRING_FWD_HPP_071894GER +#include <boost/detail/workaround.hpp> + namespace boost { namespace unit_test { template<class CharT> class basic_cstring; typedef basic_cstring<char const> const_string; + +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590041)) +typedef const_string literal_string; +#else typedef const_string const literal_string; +#endif + typedef char const* const c_literal_string; } // namespace unit_test diff -ru boost-04-08-17-0400/boost/test/detail/unit_test_parameters.hpp boost-cvs/boost/test/detail/unit_test_parameters.hpp --- boost-04-08-17-0400/boost/test/detail/unit_test_parameters.hpp 2004-07-19 14:24:32.000000000 +0200 +++ boost-cvs/boost/test/detail/unit_test_parameters.hpp 2004-08-17 17:33:31.000000000 +0200 @@ -25,19 +25,41 @@ namespace unit_test { // framework parameters and there corresponding command-line arguments -literal_string LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; // --log_level -literal_string NO_RESULT_CODE = "BOOST_TEST_RESULT_CODE"; // --result_code -literal_string REPORT_LEVEL = "BOOST_TEST_REPORT_LEVEL"; // --report_level -literal_string TESTS_TO_RUN = "BOOST_TESTS_TO_RUN"; // --run_test -literal_string SAVE_TEST_PATTERN = "BOOST_TEST_SAVE_PATTERN"; // --save_pattern -literal_string BUILD_INFO = "BOOST_TEST_BUILD_INFO"; // --build_info -literal_string CATCH_SYS_ERRORS = "BOOST_TEST_CATCH_SYSTEM_ERRORS"; // --catch_system_errors -literal_string REPORT_FORMAT = "BOOST_TEST_REPORT_FORMAT"; // --report_format -literal_string LOG_FORMAT = "BOOST_TEST_LOG_FORMAT"; // --log_format -literal_string OUTPUT_FORMAT = "BOOST_TEST_OUTPUT_FORMAT"; // --output_format - -enum report_level { CONFIRMATION_REPORT, SHORT_REPORT, DETAILED_REPORT, NO_REPORT, UNDEF_REPORT }; -literal_string report_level_names[] = { "confirm" , "short" , "detailed" , "no" }; +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590041)) +// Needed because literal_string must not be const, you get multiple defined +// symbols otherwise. (see 'basic_cstring_fwd.hpp') As an alternative, +// 'c_literal_string' could be replaced by 'literal_string const' as well. +c_literal_string LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; // --log_level +c_literal_string NO_RESULT_CODE = "BOOST_TEST_RESULT_CODE"; // --result_code +c_literal_string REPORT_LEVEL = "BOOST_TEST_REPORT_LEVEL"; // --report_level +c_literal_string TESTS_TO_RUN = "BOOST_TESTS_TO_RUN"; // --run_test +c_literal_string SAVE_TEST_PATTERN = "BOOST_TEST_SAVE_PATTERN"; // --save_pattern +c_literal_string BUILD_INFO = "BOOST_TEST_BUILD_INFO"; // --build_info +c_literal_string CATCH_SYS_ERRORS = "BOOST_TEST_CATCH_SYSTEM_ERRORS"; // --catch_system_errors +c_literal_string REPORT_FORMAT = "BOOST_TEST_REPORT_FORMAT"; // --report_format +c_literal_string LOG_FORMAT = "BOOST_TEST_LOG_FORMAT"; // --log_format +c_literal_string OUTPUT_FORMAT = "BOOST_TEST_OUTPUT_FORMAT"; // --output_format +#else +literal_string LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; // --log_level +literal_string NO_RESULT_CODE = "BOOST_TEST_RESULT_CODE"; // --result_code +literal_string REPORT_LEVEL = "BOOST_TEST_REPORT_LEVEL"; // --report_level +literal_string TESTS_TO_RUN = "BOOST_TESTS_TO_RUN"; // --run_test +literal_string SAVE_TEST_PATTERN = "BOOST_TEST_SAVE_PATTERN"; // --save_pattern +literal_string BUILD_INFO = "BOOST_TEST_BUILD_INFO"; // --build_info +literal_string CATCH_SYS_ERRORS = "BOOST_TEST_CATCH_SYSTEM_ERRORS"; // --catch_system_errors +literal_string REPORT_FORMAT = "BOOST_TEST_REPORT_FORMAT"; // --report_format +literal_string LOG_FORMAT = "BOOST_TEST_LOG_FORMAT"; // --log_format +literal_string OUTPUT_FORMAT = "BOOST_TEST_OUTPUT_FORMAT"; // --output_format +#endif + +enum report_level { CONFIRMATION_REPORT, SHORT_REPORT, DETAILED_REPORT, NO_REPORT, UNDEF_REPORT }; + +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590041)) +// See comment on workaround above. +c_literal_string report_level_names[] = { "confirm" , "short" , "detailed" , "no" }; +#else +literal_string report_level_names[] = { "confirm" , "short" , "detailed" , "no" }; +#endif enum output_format { HRF /* human readable format */, XML /* XML */ };

1 0

Fw: Re your copyright in Boost C++ Library
by John Maddock 17 Aug '04

17 Aug '04

And yet another permission.... ----- Original Message ----- From: "Lars Gullik Bjønnes" <larsbj(a)lyx.org> To: "John Maddock" <john(a)johnmaddock.co.uk> Sent: Tuesday, August 17, 2004 1:57 PM Subject: Re: Re your copyright in Boost C++ Library > "John Maddock" <john(a)johnmaddock.co.uk> writes: > > >> | Hi, if you are receiving this message it is because there are one or > | more > >> | files in the Boost C++ libraries that contain your copyright > | declaration. > >> > >> I belive that my name (and copyright) should just be removed from > >> those files. > > > | Are you sure? > > If it is ok by you, yes. > (if not just add me to the blanket file. Or do that anyway...) > > > > | You can view the two files here: > > > | http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/detail/atomic_count… > | http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/detail/lwm_gcc.hpp?… > > > | cvs revision history suggests that the implementation originally came from > | you? > > It is really something of an super simple adaptation of code that was > already in boost. And I belive that this has be rewritten a bit since > even. (and it is even buggy... or so they say :-) ) > > -- > Lgb >

1 0

Fw: Re your copyright in Boost C++ Library
by John Maddock 17 Aug '04

17 Aug '04

Another permission for out records... ----- Original Message ----- From: "Nikolay Mladenov" <nickm(a)sitius.com> To: <boost-owner(a)lists.boost.org> Sent: Tuesday, August 17, 2004 3:03 PM Subject: Re: Re your copyright in Boost C++ Library > I Nikolay Mladenov, give > permission for all my contributions to Boost to be moved to the Boost > Software License Version 1 >

1 0

ETI bug and iterators
by Yitzhak Sapir 17 Aug '04

17 Aug '04

Hello. I am in the process of upgrading code to use boost 1.31.0 for MSVC6.5. During this process I happened upon minimum_category.hpp which contains "ETI workarounds". Now, it seems that the ETI workarounds cause the compilation to fail, with the error message: constant expression expected. Particularly, we are creating zip iterators to two STLPort vectors. In debug iterator mode, I get the following error. (minimum_category.hpp was modified a bit, but the problem is in the instantiation of boost::is_same<T1 or T2,int>). If I remove the ETI "workarounds" the code compiles fine. So my question is what is ETI, what does the ETI workaround provide, and how can I benefit from both the workaround and normal use of the code? The code looks something like: std::find(boost::make_zip_iterator(boost::make_tuple(vector1.begin(), vector2.begin())), boost::make_zip_iterator(boost::make_tuple(vector1.end(), vector2.end())), ... The beginning of the error looks something like this: ./../3rdParty\boost/iterator/detail/minimum_category.hpp(86) : error C2057: expected constant expression ../../3rdParty\boost/iterator/detail/minimum_category.hpp(112) : see reference to class template instantiation 'boost::detail::minimum_category<struct boost::random_access_traversal_tag,struct boost::random_access_traversal_tag>' being compi led ../../3rdParty\boost/mpl/aux_/preprocessed/msvc60/apply.hpp(88) : see reference to class template instantiation 'boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >::apply<struct boost::random_access_travers al_tag,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/mpl/aux_/preprocessed/msvc60/apply.hpp(101) : see reference to class template instantiation 'boost::mpl::aux::msvc_apply2<struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> > >::re sult_<struct boost::random_access_traversal_tag,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/iterator/zip_iterator.hpp(173) : see reference to class template instantiation 'boost::mpl::apply2<struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >,struct boost::random_access_ traversal_tag,struct boost::random_access_traversal_tag>' being compiled Thanks.

2 1

CVS at boost-consulting.com
by Christoph Ludwig 17 Aug '04

17 Aug '04

Hi, my Boost CVS working directory used to be rooted at :pserver:anonymous@boost-consulting.com:/boost. However, for some time I didn't get any updates any more. Since it's not plausible that there were no check-ins in the last week I checked out the boost directory from SourceForge. And indeed, there are many differences between the two working directories. For instance: After `cvs up' I have revision 1.4 of boost/algorithm/string/classification.hpp in the working directory rooted at boost-consulting and its status is up-to-date according to `cvs stat' (no sticky tag or date). But in the working directory rooted at sourceforge there's revision 1.5. `cvs log' says it was checked in on 2004-07-30. Even if the CVS at boost-consulting is mirrored only once a day, revision 1.5 of boost/algorithm/string/classification.hpp should be in the repository by now. Do others experience the same problem? Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 1

[Boost-bugs] [ boost-Bugs-1010681 ] boost::filesystem::exists is broken on cygwin
by SourceForge.net 17 Aug '04

17 Aug '04

Bugs item #1010681, was opened at 2004-08-17 14:19 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=1010681&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Carlo Wood (libcw) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem::exists is broken on cygwin Initial Comment: Compile the following code snippet: #include <iostream> #include <boost/filesystem/path.hpp> #include <boost/filesystem/operations.hpp> int main() { boost::filesystem::path p = "/usr"; if (!boost::filesystem::exists(p)) std::cerr << p.string() << " doesn't exist according to boost::filesystem" << std::endl; } $ uname -a CYGWIN_NT-5.0 vmware 1.5.10(0.116/4/2) 2004-05-25 22:07 i686 unknown unknown Cygwin $ g++ -g -I"/usr/src/install/3.3.1/include/boost-1_31" test.cc -L"/usr/src/install/3.3.1/lib" -lboost_filesystem-gcc-d-1_31 $ ./a.exe /usr doesn't exist according to boost::filesystem Needless to say that /usr does exist: $ ls -ld /usr drwxrwxrwx+ 18 carlo Gebruike 4096 Aug 8 14:49 /usr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1010681&group_… ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: tru64 ICE
by David Abrahams 17 Aug '04

17 Aug '04

Daveed Vandevoorde <daveed(a)edg.com> writes: > Hello, > > On Aug 16, 2004, at 2:57 PM, David Abrahams wrote: > [...] >> This construct is causing tru64cxx6.5 to ICE. Is there any chance >> this is an old bug of yours for which you know a workaround, or is it >> all Compaq? > > We couldn't get it to abort in our released versions > of the last few years. So our suspicion is that this > is a Compaq-specific issue. > > Is there anything in the wording of the internal error > message (if any) that would indicate that it originates > in an EDG front end? Nobody showed me the actual error, so I can say. Sorry :( Thanks for looking at this. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1