March 2006 - Boost - lists.boost.org

[date_time] testgreg_serialize_dll
by Vladimir Prus 01 Mar '06

01 Mar '06

Hi, at the moment, the above tests fails on pretty much every Windows toolset, because it can't import symbols from Boost.Serialization and Boost.Date_time Here's the relevant code: [ run gregorian/testgreg_serialize.cpp <lib>../build/boost_date_time <lib>@boost/libs/serialization/build/boost_serialization : : : $(DATE_TIME_DYNAMIC_PROPERTIES) : testgreg_serialize_dll ] It seems wrong to be to use DATE_TIME_DYNAMIC_PROPERTIES (which includes <define>BOOST_ALL_DYN_LINK and at the same time link to *static* libraries. I suggest that <lib> in two places above be replaced with <dll>. Since I don't have msvc around, can somebody test that such change indeed fixes the problem? Thanks, Volodya

1 0

[SIGNAL/BIND] Regressions with GCC 4.1 RC.
by larsbj＠gullik.net 01 Mar '06

01 Mar '06

We se some strange problems with GCC 4.1 (the prerelease/release candidate) with use of boost::signal and boost::bind. Have anyone run the regressions tests for this GCC version? g++ (GCC) 4.1.0 20060219 (prerelease We get errors of this form: g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./.. -I../../boost -Wextra -Wall -I/usr/X11R6/include -g -O -MT render_graphic.lo -MD -MP -MF .deps/render_graphic.Tpo -c render_graphic.C -o render_graphic.o In file included from ../../boost/boost/config.hpp:35, from ../../boost/boost/bind.hpp:23, from ../../src/support/translator.h:16, from ../../src/graphics/GraphicsTypes.h:18, from ../../src/graphics/GraphicsLoader.h:27, from render_graphic.h:17, from render_graphic.C:13: ../../boost/boost/config/compiler/gcc.hpp:92:7: warning: #warning "Unknown compiler version - please run the configure tests and report the results" ../../boost/boost/bind.hpp: In function 'void boost::visit_each(V&, const boost::_bi::value<T>&, int) [with V = boost::signals::detail::bound_objects_visitor, T = const InsetBase*]': ../../boost/boost/bind.hpp:296: instantiated from 'void boost::_bi::list2<A1, A2>::accept(V&) const [with V = boost::signals::detail::bound_objects_visitor, A1 = boost::reference_wrapper<const LyX>, A2 = boost::_bi::value<const InsetBase*>]' ../../boost/boost/bind/bind_template.hpp:150: instantiated from 'void boost::_bi::bind_t<R, F, L>::accept(V&) const [with V = boost::signals::detail::bound_objects_visitor, R = const Buffer* const, F = boost::_mfi::cmf1<const Buffer* const, LyX, const InsetBase*>, L = boost::_bi::list2<boost::reference_wrapper<const LyX>, boost::_bi::value<const InsetBase*> >]' ../../boost/boost/bind.hpp:1110: instantiated from 'void boost::visit_each(V&, const boost::_bi::bind_t<R, F, L>&, int) [with V = boost::signals::detail::bound_objects_visitor, R = const Buffer* const, F = boost::_mfi::cmf1<const Buffer* const, LyX, const InsetBase*>, L = boost::_bi::list2<boost::reference_wrapper<const LyX>, boost::_bi::value<const InsetBase*> >]' ../../boost/boost/visit_each.hpp:25: instantiated from 'void boost::visit_each(Visitor&, const T&) [with Visitor = boost::signals::detail::bound_objects_visitor, T = boost::_bi::bind_t<const Buffer* const, boost::_mfi::cmf1<const Buffer* const, LyX, const InsetBase*>, boost::_bi::list2<boost::reference_wrapper<const LyX>, boost::_bi::value<const InsetBase*> > >]' ../../boost/boost/signals/slot.hpp:121: instantiated from 'boost::slot<SlotFunction>::slot(const F&) [with F = boost::_bi::bind_t<const Buffer* const, boost::_mfi::cmf1<const Buffer* const, LyX, const InsetBase*>, boost::_bi::list2<boost::reference_wrapper<const LyX>, boost::_bi::value<const InsetBase*> > >, SlotFunction = boost::function<void ()(), std::allocator<void> >]' render_graphic.C:44: instantiated from here ../../boost/boost/bind.hpp:1105: error: no matching function for call to 'visit_each(boost::signals::detail::bound_objects_visitor&, const InsetBase* const&, int)' This patch "fixes" the compile problems but we do not really want to apply it. Any opinions on this? Is it something strange hidden in our code, boost or a real regression in gcc? -- Lgb

3 10

[shmem] Contribution
by Michael Pryhodko 01 Mar '06

01 Mar '06

Hi I am not active 'Boost' participant, but I keep an eye on this project and check it's status from time to time. During last couple of years I was involved in IPC and was naturally intrigued by the new boost library -- Shared Memory Library. In documentation I have read that: [------- start -------] To place STL-compatible containers in shared memory, Shmem allocators define allocator<T>::pointer typedef as a relative pointer type, instead of T*. Although the use of smart pointers is allowed by the standard, current STL implementations can't handle Shmem shared memory STL compatible allocators. [------- end -------] But in my recent project I actually created allocator for shared memory that can be used in STL from MS VC7.1. Rejected two or three version of allocator::pointer until it worked. And I used it successfully: in my project complex structures with maps, deques, vectors, pointers and even smart pointers were created in shared memory. Only problem I have found -- std::basic_string, it explicitly uses T* in union. I have used limited_string or vector<char> instead of it. If anybody interested -- just ask for more details, until then I'll demonstrate simple example and allocator declaration: [------- start example -------] template<class MemModel = StdMemModel> class RootObject : public MemModel::ObjectBase { public: typedef ProcessContext<MemModel> ProcessContext; typedef typename MemModel::rebind<ProcessContext>::Allocator::pointer ProcessContextPtr; //... private: // process context map<ProcId, ProcessContextPtr> typedef std::map<DWORD, ProcessContextPtr, std::less<DWORD>, typename MemModel::rebind<std::pair<DWORD const, ProcessContextPtr> >::Allocator> ProcessMap; ProcessMap m_procMap; }; // later in the code: if (useShared) { new RootObject <SharedModel>(); } else { new RootObject <>(); } [------- end example -------] I'll try to attach shared allocator declaration, hope that this newsgroup allows this. Bye. Sincerely yours, Michael. begin 666 heap.zip M4$L#!!0````(`$-R7#0X,K$Y- <``- >```&````:&5A<"YHY5E;3]M(%'X& MB?]PVDK("0&2JGT)D(KM4O4!"@O9OE25-=ACXJUO.YY LQ'[V_?,S3.V$Q): MD"JMI2CQ^,PYWWSG,F><5W&4A32"CR?'%_Y'WQ\,_$'??]WOO_7]M_Z;@?^F M[_L79UN;KU JSNAJ012-(_#/KM[[GT\N802#?K^/@P4C-RF!/ LHWM$LC",A M+,2S()F&%%ZF-,W9;&_R4CW8W]]]BFMK,R,I+0L24% 68/Z$RI]0U?X^_$9* M>G[]%PWXUF;)V33@M2$$#GBA8):SE"3J]C:/PR[D!66$YPPR>B=&P2OC?ZC/ M(;O"[PXLON; *)^R3%,S')(DR0-/S3F >VL!K(60)I13M"#'NP4JYQ.6WWF+ MK,PKU1&CU"OJ6NNXOWR%Y\?]Y>M/X*X<4"084"G-^#H^Z$%E<8'!:BW%6H1W ME;;N0EU"W5KT/@TDS:6%M!C3W&4NRZ7,,I U]_>@Y.%PJ*?@:)!G)=^N,"LE M.BW$Q=G,WCCCXGHH8JSDO?T9$!Y,/(F ?@]HP>,\,PA66?GTY^EI6ZO+98-* M$Y2KEBQ-/BJG_J^,VD1?S>EB1N\/GKK 7^1QQBG;VN0TQ1+"Z6&0D+*$\6AK M4_W2$C"$8GJ=Q,&B#8#/"BJV;;FJ@C/<3"-<51Y%)>4^/ZA+3;,ROLEH",&$ M,+7T+ES/.-+/*F$S%S/>Y*I&XE6/2 ]P!,)IFLXL=W,HX B()$Q!'M;G-T7[ M5;0:B7$72%-*6?5(H^X&>5K$"66[Y;0HDEBL*D"7]RKG(Y0LA%"$`6$4\F]F M<A4=XRX:D30X)G60W:#)AL60DB3.;N NYA,H\F2&<5),XC+5+#<<^7I47YO^ M/L0'.NR 3<KE^>:L'?U+>!SX`2GYX;@[\G#BGD38`9-@%=(5.+8M0<\-25R: MSBY'HII(D5,,S3@@"=(ID9003;- % .DFNMZ,[9U;'>TOL=:Z]W9\=SB*:)K MYPA$3<PC;XQ3:U@;H>EJP0$W2(T$3PM/SD552U2C2%.QQ;>[V\*W^WA\J&4M M? M5&WS+&#Q2)5OO([<D:34-35:[*/0P<H> !>H;^INDK%9OM;>5UR,)G';' M)"U:JQOKP:"S/#9^S,3.$A/*2*.V\]S'><O30#FP8/$MUH!AE4$R.Y;.(a)2.L MQO ./T/ (MR1H+QJ:^C<^,6G:9+8E:OLMYN%K@IRF]4;2ZV0:T.D9LCJ)TAS MVYQ#0KNH0<1B/#U";;,\>(ZM6G8SPKT/;-:.S-S9_3;,UCL6T3#%J,#[:E\U M#TT9MB(CDTZF,!XXNJS8-C0O1B/**)ZMW0EM_<I'PHK\X3]HQ6P-]E*37%OU M!;E9H+[4LELR-JS%E])F.=IHT.V?\PEER/G&ACX3,WH=9Z$8F&_(GB"[I0S[ MD\PZY- ?ST:8-;5!.'1T&43.%/40<O$E2-E04;6A>0(2AHR6I5=1`/[G*MLK M.";HE3#F"*133JX3)2W$3/[I4K MM2B#TE[-.Y75!OUKVL[R;(GYFI4VB(H7 MT1%8IK4+D#DR3;C#K1?F\FR'O5)GD195A"S;X]'V(L77,[PI9J+C6JQQ>70L MMZ6%%AJ,6)YBA6)4* U7+F@-\V)I3KNU&@PJP@Y]?23:@69;M^!D(18-JYR) MYQ@=0OX%QQ:YRDEKV<I"+L\80+B61D0Y-M!BDNWKQ&4/),-A\Q KIKJ JA@V MB"H,X+_/IQGOZ<U)(O<_'%_^`5UQ1G#(,0`)8V0F0EK-!+0H7L"4%53DA]>A M-A)-['$+T8OW#DIKM]J3.RUBJYAI\#HVI5*FT((0JU.K3A*RT%8I*5X8*?)@ M[#4S47L5E>6SFFG7C_)IPY)X['6EY-Z_8\_1*<AQRW5*OOOBI]<L**@W3@7[ M*!&GTU1[046%*,A6AW;+$;CM4,?;'71@7[<Z(+I.-X+[<&CFO3,_AJ(1TDC- MM@YW.?LF:@)A*!/"61RPO,PCWMJ<_6,1+YB0<8;'-@2I(NMW19#/2'9#O7J4 MF$N$I7A9K'7@/F6X_A"SDO<>.^L4#TD]/;PMOM%?-6]]T8J5J/!F)++]0!N$ M%T?JR0'L[*@AZ7'4M&?"00^+#D@S9<O&^.3LXO1X? +G%R>7Q^/SRZMV*S/H M@7-@-)Q=YWEB*]B1YY2V@3DS]MQ:7ITDS1(YX@.Q&@N'_CV5QSM =7=D5@(F M!]6G31,/<L@LY@>POG@BK*BYB38B2=F$J\8L^:M;RS4NZ<6K"6$T/,NQKL(N M'D;DK?D#(Q7#U3\$CJA]0]3N6,5PK7^JO>5K-4/C$1R;&W.";W5\MIB"^A(# M5FHQ" 5$'B0:W2#^>BU..55**:"(93BLP-(a)$*V0%%.J<E9B2S]F>.3,U7T \ M%ZYZV_9X=$]\AKF7;]L;?W[]LG]]7?'PC*9G]<AVQWXRLJ5+'QG>6NG\_E>+ M;D:E3(&WZE5<W=3(*U0;I@/K5PG[1\)6#C%_%V,TK_SW^3]02P$"% `4```` M" !#<EPT.#*Q.30'``#0'@``!@`````````!`"$`)($`````:&5A<"YH4$L% 3!@`````!``$`- ```%@'```````` ` end

1 0

[tools/regression] Borland patch for process_jam_log.cpp
by Nicola Musatti 01 Mar '06

01 Mar '06

Hallo, the following patch makes it possible to compile process_jam_log.cpp with the Borland compilers. In a ternary operator the Borland compiler doesn't apply the implicit conversin from a [const] char * to a std::string. Cheers, Nicola Musatti Index: process_jam_log.cpp =================================================================== RCS file: /cvsroot/boost/boost/tools/regression/process_jam_log.cpp,v retrieving revision 1.38 diff -d -b -u -r1.38 process_jam_log.cpp --- process_jam_log.cpp 28 Jun 2005 00:24:41 -0000 1.38 +++ process_jam_log.cpp 23 Jan 2006 23:06:22 -0000 @@ -462,7 +462,7 @@ // add the "run" stop_message action tl.add_action( action_name, - result == "succeed" && note() ? "note" : result, + result == "succeed" && note() ? std::string("note") : result, timestamp, content ); }

2 1

C++ Mystery: [Fwd: Re: [Boost-users] [statechart] Template States, Compile Error]
by David Greene 01 Mar '06

01 Mar '06

Since both I and Andreas are baffled by this problem, I thought I'd forward this on to the larger Boost community. Anyone have any ideas about it? It seems like it should be a simple thing but something about the way lookup works in C++ is causing the inner_context_type member of simple_state to be missed. The problem persists even if typedef typename sc::simple_state< NormalMode< Type >, Switch, Off<Type> >::inner_context_type inner_context_type; is added to the NormalMode class template. -Dave

2 1

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