- Boost - lists.boost.org

Re: [boost] [database] - guid class / Next Release
by Marc Viala 02 Mar '06

02 Mar '06

<snip> > This does make sense. I have added a constructor to initialize from raw data: > template <ByteInputIterator> > guid(ByteInputIterator first, ByteInputIterator last); > and a function to get out the raw bytes: > template <ByteOutputIterator> > void output_bytes(ByteOutputIterator out) { > std::copy(data_.begin(), data_.end(), out); } > Is output_bytes what you are looking for? Andy. Hi Andy, I'm sorry to be quite < pushy > but are you making some progress on the next release of you proposal of guid class? The functionalities of your proposal are really present in our current project development and I would like to know when you plan to publish your next release. By the way, do you have a look on my previous email 22/02? Best regards, Marc Viala

3 3

Re: [boost] VC7.1 ICE
by Peder Holt 02 Mar '06

02 Mar '06

On 2/26/06, Tobias Schwinger <tschwinger(a)neoscientists.org> wrote: > Peder Holt wrote: > > In confix_parser_gen: > > Adding another level of indirection solves the problem: > > [...] > > > > Now rule_parser_1_1 passes without problems. > > Great! > > > > Attached is a patch with this fix. > > > > I applied the workaround to all functions in the CVS version of confix.hpp. > Unfortunately the same trick won't help to get rid of the ICE in rule_parser_2_2 when applied to the subscript operator of spirit::parser (would've been too easy)... I have looked at this, and this is a problem between VC7.1 and the way the typeof emulation works, as you showed in the simplified test-case. The problem lies in the use of the operator[] with function pointers. The only workaround for this problem that I have found, apart from rewriting the user code, is to separate the sizeof operation and the typedef. (like in the #if ! defined BOOM clause) Problem is, this has to be done inside a struct, and can not be made to emulate the BOOST_TYPEOF syntax. The proposed solution is then to add a new macro called something like: BOOST_TYPEOF_NESTED_TYPEDEF(name,expr) which looks roughly like this: struct name { //Twophase typeof using expr typedef resulting_type_calculated type; }; To access the type, you have to do a typedef typename name::type my_type; outside BOOST_TYPEOF_NESTED_TYPEDEF. Introducing this construct has two positive effects: 1. rule_parser_2_2 (and similar tests) pass. 2. In emulation mode, there is no longer any limit to the complexity of the types passed to BOOST_TYPEOF_NESTED_TYPEDEF. BOOST_TYPEOF_LIMIT_SIZE is no longer a limiting factor. The downside is the added complexity of the library. It also doesn't reflect any proposed C++ features. Is there any interest in adding this feature to the typeof library? Regards, Peder

2 2

[wave] test_re2c_lexer / V2
by Vladimir Prus 02 Mar '06

02 Mar '06

Hi, the test_re2c_lexer test of Wave fails under msvc-7.1/Boost.Build V2, as shown at: http://tinyurl.com/joupe The error says that dllimport/dllexport directives are wrong. This was not detected with V1, but V2 uses shared linking by default and so detects the problem. In other words, it's possible that the re2c lexer cannot be used when Wave is built as DLL. Hartmut, can you look into this? - Volodya

2 2

Re: [boost] VC7.1 ICE
by Tobias Schwinger 01 Mar '06

01 Mar '06

Peder Holt wrote: > Tobias Schwinger wrote: >>Unfortunately the same trick won't help to get rid of the ICE in >>rule_parser_2_2 when applied to the subscript operator of >>spirit::parser (would've been too easy)... > > > I have looked at this, and this is a problem between VC7.1 and the way > the typeof emulation works, as you showed in the simplified test-case. > The problem lies in the use of the operator[] with function pointers. > > The only workaround for this problem that I have found, apart from > rewriting the user code, is to separate the sizeof operation and the > typedef. > (like in the #if ! defined BOOM clause) > Problem is, this has to be done inside a struct, and can not be made > to emulate the BOOST_TYPEOF syntax. > The proposed solution is then to add a new macro called something like: > BOOST_TYPEOF_NESTED_TYPEDEF(name,expr) which looks roughly like this: > struct name { > //Twophase typeof using expr > typedef resulting_type_calculated type; > }; > > To access the type, you have to do a typedef typename name::type > my_type; outside BOOST_TYPEOF_NESTED_TYPEDEF. > > Introducing this construct has two positive effects: > 1. rule_parser_2_2 (and similar tests) pass. > 2. In emulation mode, there is no longer any limit to the complexity > of the types passed to BOOST_TYPEOF_NESTED_TYPEDEF. > BOOST_TYPEOF_LIMIT_SIZE is no longer a limiting factor. Wow! Sounds like a pretty cool workaround to me. Will the proposed interface allow me to inject static variables into the context the expression is evaluated in? Clarification: Using a SPIRIT_RULE_PARSER with the expression p >> *(d >> p) , p and d being templated parameters, the macro generates // ... struct __parser { // Injected names // (these are member variables in the "runtime version" of the // expression which is assigned to a member variable of type // __parser::type) static P0 & p; static P1 & d; typedef typeof( p >> *(d >> p) ) type; }; // ... Wouldn't I have to declare p and d inside the nested struct in this case? > The downside is the added complexity of the library. > It also doesn't reflect any proposed C++ features. So what? It's closer to the semantics of native typeof because the limits aren't so tight and because it's stable. It would be interesting to know whether it also eliminates the ADL failure and the weird "deduction from base fails for non-overloaded functions" bug in VC8 [ see http://tinyurl.com/7j9me ] ... > Is there any interest in adding this feature to the typeof library? YES! It also seems very well-suited for planned Spirit-2 http://spirit.sourceforge.net/dl_docs/redesigning_spirit.html as we'll easily hit the current limits trying to handle the results of the proposed kind of parser-transformation, I figure. In fact, I was tempted to make "subexpression registration" [ discussed with Arakdiy here: http://tinyurl.com/asnxq ], which can significantly reduce the required TYPEOF_LIMIT_SIZE, an official feature request for Typeof after reading that document. Thanks again -you da man- ;-), Tobias

1 0

[MPL] lambda and gcc 4
by João Abecasis 01 Mar '06

01 Mar '06

Hi! Using current CVS or version 1.33.1 the following simplified test case fails to compile with gcc 4.0.2 #include <boost/mpl/lambda.hpp> int main() { using boost::mpl::lambda; typedef lambda<lambda<int> >::type type; } What I'm actually trying to do is mpl::transform< PredSequence, mpl::lambda<mpl::_1> > , where PredSequence is a MPL Sequence. The result of this operation is subsequently used with fold/reverse_fold to chain together all the metafunctions in PredSequence and create a single metafunction, where the result of one metafunction is passed as argument to the next. For the current CVS HEAD the errors I get with the above test case are, boost/mpl/aux_/preprocessed/gcc/template_arity.hpp: In instantiation of ‘boost::mpl::aux::template_arity<T1>’: test.cpp:7: instantiated from here boost/mpl/aux_/preprocessed/gcc/template_arity.hpp:98: error: ‘boost::mpl::aux::template_arity<T1>::value’ is not a valid template argument for type ‘int’ because it is a non-constant expression test.cpp: In function ‘int main()’: test.cpp:7: error: ‘boost::mpl::aux::template_arity<T1>::value’ is not a valid template argument for type ‘int’ because it is a non-constant expression test.cpp:7: error: ‘boost::mpl::aux::template_arity<T1>::value’ is not a valid template argument for type ‘int’ because it is a non-constant expression The full compiler version is 4.0.2 20051125 (Red Hat 4.0.2-8), from Fedora Core 4. When using gcc 3.2.3 from the same linux distribution both simplified test and the real use case compile cleanly. Am I doing something wrong? What am I missing? Best regards, João

1 0

[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