- Boost - lists.boost.org

Statechart bug? [Fwd: [Boost-users] [statechart] Template States, Compile Error]
by David Greene 01 Mar '06

01 Mar '06

Forwarding because this might be a library bug. I can't figure out why these error messages are generated. -Dave

2 1

[serialization] [ublas] - ublas::matrix, ublas::vector serialization patch
by Janek Kozicki 01 Mar '06

01 Mar '06

hi serialization of ublas matrix and vector is missing in boost 1.33, therefore I've written missing functions: /usr/include/boost/serialization/ublas_matrix.hpp /usr/include/boost/serialization/ublas_vector.hpp files are in the attachment. I'm afraid that the idea of converting matrix to std::vector<std::vector<U> > is not optimal, perhaps someone can make it better? Please include those files in next boost version. File are very short, so review should not take too long. I bet that some people out there need them. best regards -- Janek Kozicki |

3 6

Sourceforge + Subversion (finally)
by Caleb Epstein 01 Mar '06

01 Mar '06

I think Boost already has another host in mind for an eventual (?) switch to Subversion, but in case I'm wrong it appears that Sourceforge now officially supports Subversion repositories: http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1 They even offer automatic repository conversion (e.g. cvs2svn). -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

[shmem] Some proposals for open issues from the review
by Ion Gaztañaga 01 Mar '06

01 Mar '06

Hi to all, After Shmem review, I've been re-reading some review comments and there were some issues not completely solved during the review: * Library name: Some don't like the Shmem name for the library and since the library offers also a process shared message queue and memory mapped files and surely we will have more interprocess mechanisms in the future (pipes, for example), I'm proposing the Boost.IPC or Boost.InterProcess name (boost::ipc or boost::interprocess namespace). I don't know if it's even worse or if it expresses better the purpose of the library. Just an idea. * Class names: I propose changing "mmaped_file" class to simply "mapped_file", so we have "mapped_file" and "mapped_region" classes. The classes that I call "front-ends" (a name that some don't like and if someone has a better I would be glad to use it) have the following names: ->named_shared_object (the class that allows named object construction in shared memory) ->named_mfile_object (the class that allows named object construction in memory mapped files) ->named_heap_object (the class that allows named object construction in a heap memory buffer) ->named_user_object (the class that allows named object construction in an user provided buffer) I don't like much those names but I couldn't find better alternatives. In response to Kim Barrett's review I proposed the following: ->shared_memory_xxx ->mapped_file_xxx ->heap_memory_xxx ->external_memory_xxx where xxx can be something like "services", "framework", "objects", or we can add a "smart" prefix to those names. I would like to receive suggestions for better names. I think it's important to choose better names before the library is released. * Changes from Boost.Thread interface: Now that Boost.Date_Time has been chosen as time representation for timed functions of the synchronization primitives, I would also propose a simplification of synchronization primitives. Currently, following Boost.Thread interface, mutex lock and unlock functions are private, but I would prefer making them public, and implement a unique scoped lock class that can lock any "lockable" object (shared_mutex, shared_recursive_mutex, named_mutex). This general locker could be moved to boost utilities or be just for this library. Or do you consider "too dangerous" to have lock functions public?. This is a proposal based on Howard Hinnant's much more complete scoped_lock proposal (http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html) namespace boost { namespace shmem/ipc/interprocess { template <class Mutex> class scoped_lock { public: typedef Mutex mutex_type; explicit scoped_lock(mutex_type& m); scoped_lock(mutex_type& m, detail::dont_lock_type); scoped_lock(mutex_type& m, detail::try_lock_type); scoped_lock(mutex_type& m, const boost::posix_time::ptime &time); private: scoped_lock(scoped_lock const&); scoped_lock& operator= (scoped_lock const&); public: ~scoped_lock(); public: void lock(); bool try_lock(); bool timed_lock(const boost::posix_time::ptime &time); void unlock(); bool locked() const; operator unspecified_bool_type () const; mutex_type* mutex() const; private: mutex_type& m_mut; bool m_locked; }; }} This locker can be used would be usable with any class that has required lock()/unlock/try_lock()/timed_lock() functions. The mutex doesn't need try_lock/timed_lock functions if we don't use scoped_lock's try_lock/timed_lock functions. Since the class is a template, try_lock()/timed_lock() won't be instantiated. I also think that there too many mutex types: -> shared_mutex -> shared_try_mutex -> shared_timed_mutex -> shared_recursive_mutex -> shared_recursive_try_mutex -> shared_recursive_timed_mutex -> named_mutex I think that all can be condensed in shared_mutex, shared_recursive_mutex and named_mutex types without overhead, since Windows and POSIX systems offer try/timed functions for mutexes. So we can pass from 7 mutex types to 3 and from 3 lockers to just 1. To sum up proposals regarding this point: -> Public lock/unlock functions? -> Merging 7 mutex types into 3? -> Merging 3 scoped_lock types into 1? Regards, Ion

12 24

[serialization] CW8.3 patch
by David Abrahams 28 Feb '06

28 Feb '06

The enclosed patch makes serialization work with CW8.3 -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[parameter] Can't piecewise compose arguments.
by Rene Rivera 28 Feb '06

28 Feb '06

I'm using the Parameters lib in class constructors. In which case I end up having to piecewise build argument lists as classes call the superclass ctors. But as it turns out it doesn't compile, for example: #include <boost/parameter.hpp> namespace Param { BOOST_PARAMETER_KEYWORD(Tag,a0) BOOST_PARAMETER_KEYWORD(Tag,a1) BOOST_PARAMETER_KEYWORD(Tag,a2) } struct A { template <typename ArgPack> A(ArgPack const & args) { int i = args[Param::a0]; int j = args[Param::a1]; } }; struct B : A { template <typename ArgPack> B(ArgPack const & args) : A((args, Param::a0 = 1)) { } }; void param_test() { A a((Param::a0 = 1, Param::a1 = 13, Param::a2 = 6)); B b0((Param::a1 = 13)); B b1((Param::a1 = 13, Param::a2 = 6)); //!! } The "b1" declaration doesn't compile, although it seems like it should. The reason is simple enough, the operator,() in arg_list isn't const which causes a no function match error. The fix is obvious: ===boost/parameter/aux_/arg_lit.hpp=== @@ -311,5 +311,5 @@ template <class KW, class T2> arg_list<tagged_argument<KW, T2>, self> < operator,(tagged_argument<KW,T2> x) -> operator,(tagged_argument<KW,T2> x) const { return arg_list<tagged_argument<KW,T2>, self>(x, *this); ====== Sorry if I don't have reasonable diff, this is from Perforce :-( Is there a rational for the operator,() not being const? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 1

[tools/regression] Borland patch for compiler_status.cpp
by Nicola Musatti 28 Feb '06

28 Feb '06

Hallo, the following patch makes it possible to compile compiler_status.cpp with the Borland compilers. Apparently under some conditions the Borland compiler issues an error for a valid use of the ternary operator. It is sufficient to wrap the whole expression in parentheses to overcome the problem. The same workaround is applied twice in the patch. Cheers, Nicola Musatti Index: compiler_status.cpp =================================================================== RCS file: /cvsroot/boost/boost/tools/regression/compiler_status.cpp,v retrieving revision 1.38 diff -d -b -u -r1.38 compiler_status.cpp --- compiler_status.cpp 19 Jun 2005 21:08:17 -0000 1.38 +++ compiler_status.cpp 23 Jan 2006 23:06:22 -0000 @@ -400,13 +400,16 @@ bool always_show_run_output = false ) { // compile msgs sometimes modified, so make a local copy - string compile( (pass && no_warn) - ? empty_string : element_content( db, "compile" ) ); + // extra parentheses needed to workaround a Borland bug + string compile( ( (pass && no_warn) + ? empty_string : element_content( db, "compile" ) ) ); const string & link( pass ? empty_string : element_content( db, "link" ) ); const string & run( (pass && !always_show_run_output) ? empty_string : element_content( db, "run" ) ); - string lib( pass ? empty_string : element_content( db, "lib" ) ); + + // extra parentheses needed to workaround a Borland bug + string lib( ( pass ? empty_string : element_content( db, "lib" ) ) ); // some compilers output the filename even if there are no errors or // warnings; detect this if one line of output and it contains no space.

1 0

[build] Please add borland-5_8_1-tools.jam to v1
by Nicola Musatti 28 Feb '06

28 Feb '06

Hallo, I attached borland-5_8_1-tools.jam which is really a copy of borland-5_6_4-tools.jam modified to use a different BCC_XXX_ROOT variable. Adding this file to tools/build/v1 would make it easier to use the two latest Borland compiler releases at the same time. Thank you, Nicola Musatti # (C) Copyright David Abrahams 2002. # Distributed under the Boost Software License, Version 1.0. # (See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt) # The following #// line will be used by the regression test table generation # program as the column heading for HTML tables. Must not include version number. #//<a href="http://www.borland.com/bcppbuilder/freecompiler/">Borland</a> { BCCROOT = $(BCC_581_ROOT) ; extends-toolset borland ; C++FLAGS = [ difference $(C++FLAGS) : -WU ] ; CFLAGS = [ difference $(CFLAGS) : -WU ] -DBOOST_ALL_NO_LIB=1 ; LINKFLAGS = [ difference $(LINKFLAGS) : -WU ] ; }

1 0

Re: [boost] [multi_index] key swap status
by gruenedd＠idmt.fraunhofer.de 28 Feb '06

28 Feb '06

Joaquín Mª López Muñoz wrote: > c.insert(std::make_pair(0,1)); > c.insert(std::make_pair(1,0)); > c.insert(std::make_pair(1,1)); > c.swap_keys(c.begin(),++c.begin()); // would yield a duplicate element (1,1) > ... it implies that a possible outcome > of swap_keys() is that both elements get deleted That`s what i would expect here. :] Now, why is this surprising? Consider the following snippet: multi_index_container<int> c; // default "set"-like c.insert(1); c.insert(2); c.modify_key(--c.end(), _1 = 1); Isn`t it "surprising" in the same way, that c.size() == 1? ;-) > On another issue, you might be interested to know that the problem > you brought forward in > > http://lists.boost.org/Archives/boost/2005/02/80589.php > > has been solved in 1.34 Nice! Best Regards, David. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

2 2

[bind] Borland 2006 patch
by AlisdairM 28 Feb '06

28 Feb '06

The following workaround needs to be updated for BCB2006. Note I have also switched T const to const T. This does not show up in any of the regression tests, but should make a difference (to Borland) when T is a reference type. Don't ask!! cvs diff -u -wb -- boost\ref.hpp (in directory E:\sourceforge\devel\boost\) Index: boost/ref.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/ref.hpp,v retrieving revision 1.23 diff -u -w -b -r1.23 ref.hpp --- boost/ref.hpp 28 Nov 2004 03:20:58 -0000 1.23 +++ boost/ref.hpp 27 Feb 2006 07:57:50 -0000 @@ -54,7 +54,7 @@ T* t_; }; -# if defined(__BORLANDC__) && (__BORLANDC__ <= 0x570) +# if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT(0x581) ) # define BOOST_REF_CONST # else # define BOOST_REF_CONST const @@ -65,9 +65,9 @@ return reference_wrapper<T>(t); } -template<class T> inline reference_wrapper<T const> BOOST_REF_CONST cref(T const & t) +template<class T> inline reference_wrapper< const T > BOOST_REF_CONST cref(const T & t) { - return reference_wrapper<T const>(t); + return reference_wrapper< const T >(t); // Test this with const T before submitting patch } # undef BOOST_REF_CONST -- AlisdairM

5 13