- Boost - lists.boost.org

[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

[test][mpl][preprocessor] borland 8.1 faiilure
by Gennadiy Rozental 28 Feb '06

28 Feb '06

Could anyone please advise on this failure: http://tinyurl.com/s8ysf? Gennadiy

2 1

[date_time] i/o formatting
by Yuval Ronen 28 Feb '06

28 Feb '06

Hi. I've used the date_time I/O using facets and found it too complicated. The thing that bothers me is that I need to use a facet to specify the format string (e.g "HH:MM:SS"). This is burdensome. IMO, using facets is fine for defining things which are really locale-related (and are mostly constant during the process lifetime) such as the month names in the local language. The format is not such a property and can often change throughout the application, and as such is much better handled using an I/O manipulator: cout << time_format("HH:MM:SS") << my_ptime << endl; or if this is impossible, then cout << time_io(my_ptime, "HH:MM:SS") << endl; which surely is possible. I think of specifying the format string as similar to specifying the printing precision of a float, or specifying that an integer should be printed as hex. These are provided as manipulators without the complexity of facets (which most users, including me, know very little about). BTW, this is not my original idea. I saw it in a post (don't remember by whom) in this mailing list a few months ago. Thanks, Yuval

6 18

what's up with mpl/bool.hpp?
by Arkadiy Vertleyb 28 Feb '06

28 Feb '06

Was it broken and then promptly fixed? http://tinyurl.com/gy456 Regards, Arkadiy

2 1