- Boost - lists.boost.org

Suggestion for weak_ptr's
by Jeff Williams 18 Aug '04

18 Aug '04

Simply small change, curious as to what others think: I'll illustrate with a trivial example: struct foo { virtual ~foo() { } }; struct bar : foo { }; typedef shared_ptr<foo> fooptr; typedef shared_ptr<bar> barptr; void some_func(weak_ptr<foo> wf) { barptr pb = wf.lock<bar>(); } // currently the way to do this is (as I am sure everyone knows) void some_func(weak_ptr<foo> wf) { barptr pb = dynamic_pointer_cast<bar>(wf.lock()); } My suggestion seems easier to read. Would require no additional overhead and would preserve existing behavior. I suppose you could provide a static and dynamic version: lock_static<bar> and lock_dynamic<bar> Any thoughts? Or is the general concensus that ideas like this are something indivudual people should do in their own source? Jeff

3 2

Intel: different macros for Windows and Linux
by Stefan Slapeta 18 Aug '04

18 Aug '04

I would like to introduce different config macros for the windows and linux version of ICL which should be defined like BOOST_INTEL. The names should be BOOST_INTEL_WIN and BOOST_INTEL_LINUX. It's just to improve the control over the completely different front ends of these compilers.... (actually they are two different compilers. In many cases it doesn't make sense to make behaviour dependent on "the" Intel compiler!) OK to commit? Stefan --- intel.hpp 29 Jun 2004 10:19:27 -0000 1.36 +++ intel.hpp 18 Aug 2004 10:00:24 -0000 @@ -29,6 +29,12 @@ #define BOOST_COMPILER "Intel C++ version " BOOST_STRINGIZE(BOOST_INTEL_CXX_VERSION) #define BOOST_INTEL BOOST_INTEL_CXX_VERSION +#ifdef _WIN32 +# define BOOST_INTEL_WIN BOOST_INTEL +#else +# define BOOST_INTEL_LINUX BOOST_INTEL +#endif + #if (BOOST_INTEL_CXX_VERSION <= 500) && defined(_MSC_VER) # define BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS # define BOOST_NO_TEMPLATE_TEMPLATES

2 3

[boost-sandbox] deleting old stuff
by Thorsten Ottosen 18 Aug '04

18 Aug '04

Hi all, Does anybody know a quick way fo deleting old libaries in the sandbox? Thanks Thorsten

2 2

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

18 Aug '04

> -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > > "Yitzhak Sapir" <yitzhak.sapir(a)actimize.com> writes: > > >> -----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' > > Does the enclosed patch fix it? > No. I get the following: ../../3rdParty\boost/iterator/detail/facade_iterator_category.hpp(146) : error C2516: 'Traversal' : is not a legal base class ../../3rdParty\boost/iterator/detail/facade_iterator_category.hpp(145) : see declaration of 'Traversal' C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\stlport\stl/_algobase.c(196) : see reference to class template instantiation 'boost::detail::iterator_category_with_traversal<struct _STL::output_iterator_tag,int>' being compiled 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: #include "stdafx.h" #include <boost/iterator/zip_iterator.hpp> #include <boost/tuple/tuple.hpp> #include <vector> #include <algorithm> class c1 {}; class c2 {}; typedef std::vector<c1> c1_vec_t; typedef std::vector<c2> c2_vec_t; using namespace boost; void f(const tuples::tuple<c1, c2>& param) { } int main(int argc, char* argv[]) { c1_vec_t vec1; c2_vec_t vec2; make_zip_iterator(make_tuple(vec1.begin(), vec2.begin())); return 0; } If the ETI workarounds in minimum_category.hpp are removed the above code compiles fine.

2 1

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