- Boost - lists.boost.org

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

[boost.test] basic_cstring troubles with tru64cxx65
by Markus Schöpflin 17 Aug '04

17 Aug '04

I think I have found the source of the internal compiler errors currently preventing boost.test to work with the toolset tru64cxx65. The following small sample fails to compile and gives me an internal compiler error when compiled with cxx. ---%<--- #include <boost/test/detail/basic_cstring/basic_cstring.hpp> using namespace boost::unit_test; // void foo(const_string const & s) // ok void foo(const_string s) // not ok { } int main() { foo(literal_string("foo")); return 0; } --->%--- Changing the declaration of foo() makes the compiler error go away. I'm currently thinking that the compiler perhaps has problems with the automatically generated copy constructors for the class basic_cstring. I tried writing an explicit copy constructor for basic_cstring but this doesn't seem to help. The compiler still crashes. Maybe someone else working with this platform has any ideas... Markus

2 3

Re: [boost] Re: 31 character limit for filenames
by Steve Ramsey 17 Aug '04

17 Aug '04

On Mon, 16 Aug, 2004, at 11:34 pm, Miro Jurisic wrote: > Steve Ramsey <steve(a)lucena.com> wrote: >> FSRefs can only refer to pre-existing file system objects - this >> merited a >> single sentence in a single tech note far away from the File Manager >> documentation - which makes them bloody useless for general path >> conversions. > > You probably want CFURL APIs for path conversions. However, you should > explain a > little more what you mean by path conversions, as there are some > non-trivial and > very subtle issues regarding HFS paths and Unicode characters. (But > they may be > completely irrelevant to you, which is why I ask what you mean.) I'm not sure sure how helpful the CFURL stuff is for what I'm doing, as I'm not sure there's an easy way to get HFS paths out of them when running under OS X (as I hinted before, why on earth would you want an HFS path at all under OS X, except to make the MSL happy). The path conversion was an obscure reference to one of my failed cunning plans to convert POSIX paths to HFS paths by having FSPathMakeRef/FSRefMakePath do the work for me; I was toggling the gestaltFSUsesPOSIXPathsForConversion bit in the gestaltFSAttr Gestalt selector between calls. This fails in the general case since FSRefs can't refer to non-existent objects, but it neatly side-steps the text encoding issues when the object does exist. In the absence of system-level hacks, I'm hoping this sort of path conversion isn't the answer. I'm now looking into re-writing certain low-level MSL source files such as path2fss.c to use POSIX paths instead of HFS paths, as there is precedent for Boost libraries providing alternative MSL files to overcome certain deficiencies (boost::thread, for example). Really, though, at this point I'm just fishing while I wait for an elegant solution to suggest itself, where elegant is something other than writing off the MSL for Mac development. Here's a quick summary of what I'm dealing with: the goal is to be able to use boost::filesystem with Metrowerks CodeWarrior and the Metrowerks StdLib/STL implementation, MSL, on a CFM Carbon program intended to run under OS 9 and OS X. Ideally, only a source implementation should be necessary, and the interface files and MSL source should be off-limits (although I'm thinking some interface files needs to be changed to be more generic, e.g. handle-body idiom for path, or I need to throw this restriction out and just litter the interface files with more preprocessor conditionals and give the classes target-specific privates). The POSIX path will not work in this scenario since the MSL uses HFS paths (HFS paths: multi-root, colon delimiters, specify relative paths in the reverse fashion of POSIX, often Pascal strings in Carbon API calls, C strings in MSL calls). You can get a lot of mileage out of a proper rewrite of fs::path::native_file_string, but for total compliance work also needs to be done in fs::operations. Without system-level conversions to handle all the gritty details, the key solution here will probably be to write a heroically specialized manual HFS<->POSIX path converter that takes into account things like multiple roots (e.g., faking a /Volumes directory under OS 9), File Manager name mangling, and possible weird issues with aliases and symbolic links (mmm...cross-volume aliases). I'd _really_ like to avoid going this route... Steve

2 1