- Boost - lists.boost.org

Fw: Boost
by John Maddock 18 Aug '04

18 Aug '04

Another permission: ----- Original Message ----- From: "Maarten" <mkeijzer(a)xs4all.nl> To: <boost-owner(a)lists.boost.org> Sent: Wednesday, August 18, 2004 8:30 PM Subject: Boost > License Permission > Date: Wed, 18 Aug 2004 21:30:43 +0200 > User-Agent: KMail/1.6.2 > MIME-Version: 1.0 > Content-Disposition: inline > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > Message-Id: <200408182130.43251.mkeijzer(a)xs4all.nl> > Status: R > X-Status: NQ > X-KMail-EncryptionState: > X-KMail-SignatureState: > X-KMail-MDN-Sent: > > I Maarten Keijzer, give > permission for all my contributions to Boost to be moved to the > Boost Software License Version 1 > > I think this involves a single file in the detail section of the > interval library. FYI. > > -Maarten- >

1 0

Re: lightweight replacement for boost::function
by Max Khesin 18 Aug '04

18 Aug '04

John, just in case you missed this there is a similar effort happening here (from a competing GUI library!): http://tinytl.sourceforge.net/ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

python/embedding fails under Intel 8
by Stefan Slapeta 18 Aug '04

18 Aug '04

Maybe somebody who is more experienced with boost.python than me could have a look at this: http://tinyurl.com/6p8zf. Thanks, Stefan

3 7

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

18 Aug '04

> -----Original Message----- > From: David Abrahams > > "Yitzhak Sapir" writes: > > > 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: > > Not for me. Of course I had to remove the include of stdafx.h since > I don't have that, but the first error is: > > Dave Abrahams The problem is with debug STLPort iterators, not the pointer iterators that you get in non-debug iterators mode. Yes, release compiles fine for me with the additional BOOST_TT_BROKEN_COMPILER_SPEC. But I also want to be able to compile in debug, with the debug STLPort iterators. :-) Also, when I speak of ETI workarounds removed, I speak only of the #ifdefed lines in the following block: typedef minimum_category_impl< # if BOOST_WORKAROUND(BOOST_MSVC, == 1200) // ETI workaround is_same<T2,int>::value || # endif ::boost::is_convertible<T1,T2>::value , ::boost::is_convertible<T2,T1>::value # if BOOST_WORKAROUND(BOOST_MSVC, == 1200) // ETI workaround || is_same<T1,int>::value # endif > outer; I didn't notice there was another ETI workaround before.

2 1

algorithm/minmax_element regression with Comeau
by Bronek Kozicki 18 Aug '04

18 Aug '04

Following error http://tinyurl.com/5t7cj is due to too strict requirements of libcomo (at least I believe so). I received fix from Comeau Computing (stl_algo.h, too large to send as attachment with this message) and deployed it, tommorow we shall see this error gone. Again, I deployed it without stopping regression tests, thus next results in como-win32-4.3.3-vc7.1 may be screwed. B.

2 1

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