- Boost - lists.boost.org

Problem with boost::iterator_value
by Alex Chovanec 18 Aug '04

18 Aug '04

Hi, The following code does not compile under vc7.0-stlport-4.6.2: struct foo {}; typedef std::vector<int> vector_int; typedef std::vector<foo> vector_foo; BOOST_STATIC_ASSERT(( boost::is_same< int, boost::iterator_value<vector_int::iterator>::type>:: value)); BOOST_STATIC_ASSERT(( boost::is_same< foo, boost::iterator_value<vector_foo::iterator>::type>:: value)); Obviously, neither of these assertions should fail, but the second one does. I'm guessing that this is a problem with boost::iterator_value. Does anyone know how to fix this? Thanks, Alex

3 2

[boost.range] post-review
by Thorsten Ottosen 18 Aug '04

18 Aug '04

Dear All, Finally I have written the documentation for boost.range. Everyone who is interested should take a look at it all in the cvs and let me know what you think. (If you don't have cvs access, just mail me so I can send it) There is one major decisions that I think should be decided upon in this post-review, ans it is about naming. The boost iterators new iterator traits has this naming scheme: iterator_value<T>::type iterator_difference<T>::type I have used this scheme (originally proposed by Peter Dimov) iterator_of<T>::type value_type_of<T>::type. The question is now if the range librray should do as the iterator library, ie, prefix everyhitng with "range_": range_iterator<T>::type range_value_type<T>::type etc. br Thorsten

8 25

intrinsice 64 bit integers
by Robert Ramey 18 Aug '04

18 Aug '04

In testing the serialization library it has come to my attention that at least the two compilers on 64 bit platforms use something like typedef long int int64_t; typedef long unsigned int uint64_t; This is causing me some problems. At the same time some compilers have typedef short int wchar_t; This would cause similar problems for me except for the fact that we have BOOST_NO_INTRINSIC_WCHAR_T So I can skip over them at the preprocessor level. Is there any reason we can't add to the config files? BOOST_NO_INTRINSIC_INT64 BOOST_NO_INTRINSIC_UINT64 Robert Ramey

2 1

Passing variables to bjam when run by regression.py?
by Markus Schöpflin 18 Aug '04

18 Aug '04

Hello, I need to pass some variables (PYTHON_...) to bjam in order to compile the python tests. When invoking bjam directly, boost.build picks up those variables from the environment automatically. When running the regression tests with regression.py, the environment variables seem to be ignored, because I get a warning that my python installation is not found. How do I pass environment variables to boost.build when running it from regression.py? Or is there some other way to pass arguments to bjam when it is run by regression.py? TIA, Markus

1 0

Metacomm STLport regressions generally failing
by Michael Stevens 18 Aug '04

18 Aug '04

Hi Aleksey, It seems that the STLport tests 'msvc- stlport' and 'intel- win32- 7.1- vc6- stlport- 4.5.3' for many libraries are failing with the same error. They report the library 'stlport_vc6_stldebug.lib' as missing. No idea why this should be! Thanks for the great work and very useful test runs. I'm grinding uBLAS back to VC6 compaitbility! Michael

1 0

Metacomm
by Michael Stevens 18 Aug '04

18 Aug '04

intel- win32- 7.1- vc6- stlport- 4.5.3 msvc- stlport -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

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

18 Aug '04

> -----Original Message----- > From: Yitzhak Sapir > I can't send my own code, but the following code causes the > previously described error with an unpatched > minimum_category.hpp and an ICE when compiled with patched > and unpatched minimum_category.hpp: I meant an ICE with patched only. Sorry about that.

1 0

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

18 Aug '04

> Because I get duplicated symbols when linking otherwise. > Therefore you > need to use either > > c_literal_string LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; > > or > > literal_string const LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; > > in the header file. > > Markus I would unconditionally add static to all parameter definitions instead. Gennadiy.

2 1

[inspect] Update on inspection tests...
by Rene Rivera 18 Aug '04

18 Aug '04

Here's a summary of the latest state of the Boost tree: 8101 files scanned 680 directories scanned 221 problems reported problem counts: 1 files with invalid line endings 0 bookmarks with invalid characters 1 invalid urls 99 broken links 46 unlinked files 60 file names too long 14 files with tabs As you can see some TABS have crept in. And a fair number of files break the 31 character limit. And for license and copyrights: 8101 files scanned 680 directories scanned 4657 problems reported problem counts: 3230 files missing Boost license info 1427 files missing copyrights Slowly but surely it's improving. More details at: http://www.boost.org/regression-logs/ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

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