October 2010 - Boost-users - lists.preview.boost.org

[mpl] Iterator Concept Checking?
by Stirling Westrup 04 Nov '10

04 Nov '10

I am writing some algorithms to operate on MPL sequences, and I would like to use some form of concept checking to ensure that the types passed in that are supposed to be iterators are, in fact, iterators. The MPL library doesn't seem to have is_XXX_iterator<T> checks, and I have run into some difficulties in determining how to write them. The MPL documents state that a random_access_iterator is a 'refinement' of a bidirectional_iterator which is a 'refinement' of a forward_iterator, but its not clear what refinement means in this context. I initially assumed that this meant that a random_access_iterator_tag was derived from a bidirectional_iterator_tag which was derived from a forward_iterator_tag. This does not appear to be the case, so the obvious test for an iterator (checking that the class contains a member named 'category' that is a type derived from the iterator tag of the least acceptable iterator) will not work. I am sure I could cobble together something that would work by examining the internals of the library, but I would far rather have some guidance on the correct way to see if an iterator matches a given iterator model, within the API of the library. Does anyone have any suggestions? -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com

2 3

Polymorphic serialization with polymorphic archives problems... [part 2]
by Bogdan 03 Nov '10

03 Nov '10

First I would like to confirm I tested Robert Ramey's fix (@60273) for multiple registrations and it looks good in my runs. Thank you Robert! On the other hand, I am under the impression there is a bug in void_caster::recursive_unregister(), although I am not 100% certain about the reason: that function member is called in the destructors of the void caster template classes and makes use of the void_caster_registry singleton (more specifically the type_set). I believe it searches the set for all the void caster entries that are descendants of the current one (i.e., the one being destroyed) and performs the following ops: - delete the shortcuts. - remove the corresponding entries from the set. However, void_caster::recursive_unregister() DOESN'T REMOVE FROM THE REGISTRAR the entry corresponding to the current void_caster(). This creates the problem below: consider a scenario where a dll containing some serialization functionality is loaded explicitly at runtime (i.e., using LoadLibrary() on Windows or dlopen on Unix). There are no parent-child relationships among the serialized classes registered by that DLL: all serialized classes are derived from one abstract base. While unloading the library, its void_caster singletons are destroyed but there are no shortcuts to remove from the global registrar since there are no parent-child relationships. All entries corresponding to those are still in the global registrar and POINT TO THE void_caster SINGLETONS ALREADY DESTROYED AND DISCARDED. When the main process exits, the registrar traversal repeats for whatever process-bound void_caster singletons are about to be destroyed. During these subsequent traversals, void_caster::recursive_unregister() visits the entries left after the previous explicit dll download and tries to identify the parent-child relationship. In doing so, it accesses the dangling vc pointers generating access violations: void_cast.cpp(Line 286): const void_caster * vc = *it; void_cast.cpp(Line 287): if(vc->m_parent == this){ //<--------------------- here is the access violation I can reproduce the crash systematically, but I am not sure about the reason or whether a simple unregistration is enough. I believe this is (again) a question for Robert, but I thank for any feedback I might get. Bogdan

2 1

[proto] : Using proto with NVIDIA CUDA nvcc (redux)
by Manjunath Kudlur 03 Nov '10

03 Nov '10

I remember there were postings in this mailing list before about trying to using proto with NVIDIA's CUDA compiler, and Joel Falcou has contributed some code to make proto work with nvcc. Well, I was trying few experiments with the most recent CUDA compiler release (3.2). I believe one of the exciting things about using proto with CUDA is the ability to write mini programs in different DSELs using proto and ship the mini programs over to the "device" side and execute it there. This idiom will look as follows : template<typename F> __global__ void kernel(F f) { f(...); } kernel<<<blocksize, gridsize>>>(a+b /* a big proto expression */); I tried to write the simplest form of the above use case : #include <boost/proto/proto.hpp> namespace proto=boost::proto; template<typename> struct expr; struct domain : proto::domain<proto::pod_generator<expr> > {}; template<typename E> struct expr { BOOST_PROTO_BASIC_EXTENDS(E, expr<E>, domain) }; template<typename F> __global__ void kernel(F f) { } struct term {}; expr<proto::terminal<term>::type> a = {{{}}}; expr<proto::terminal<term>::type> b = {{{}}}; expr<proto::terminal<term>::type> c = {{{}}}; int main() { kernel<<<1,1>>>(proto::deep_copy(b+c)); return 0; } Note the deep_copy when passing proto expression to kernel functions. Since proto captures terminals by reference, the host side pointers that are held in proto expressions won't make sense on the device side, so at the very least, we have to make copies of terminals before passing to the device. Now, compiling the above program with nvcc (CUDA 3.2, host compiler gcc 4.4.3, Ubuntu 10.04) results in the following error (besides spewing a bunch of warnings) : $ nvcc -v -keep t.cu -I $HOME/boost/boost-trunk/ ... t.cudafe1.stub.c: In function ‘void __device_stub__Z6kernelI4exprIN5boost5proto7exprns_10basic_exprINS2_3tag4plusENS2_7argsns_5list2IS0_INS4_IS6_NS8_IS0_INS4_INS5_8terminalENS7_4termI4termEELl0EEEESE_EELl2EEEES0_INS4_IS9_NSA_IiEELl0EEEEEELl2EEEEEvT_(_Z4exprIN5boost5proto7exprns_10basic_exprINS1_3tag4plusENS1_7argsns_5list2IS_INS3_IS5_NS7_IS_INS3_INS4_8terminalENS6_4termI4termEELl0EEEESD_EELl2EEEES_INS3_IS8_NS9_IiEELl0EEEEEELl2EEEE&)’: t.cudafe1.stub.c:8: error: invalid cast from type ‘const expr<boost::proto::exprns_::basic_expr<boost::proto::tag::address_of, boost::proto::argsns_::list1<expr<boost::proto::exprns_::basic_expr<boost::proto::tag::plus, boost::proto::argsns_::list2<expr<boost::proto::exprns_::basic_expr<boost::proto::tag::plus, boost::proto::argsns_::list2<expr<boost::proto::exprns_::basic_expr<boost::proto::tag::terminal, boost::proto::argsns_::term<term>, 0l> >, expr<boost::proto::exprns_::basic_expr<boost::proto::tag::terminal, boost::proto::argsns_::term<term>, 0l> > >, 2l> >, expr<boost::proto::exprns_::basic_expr<boost::proto::tag::terminal, boost::proto::argsns_::term<int>, 0l> > >, 2l> >&>, 1l> >’ to type ‘char*’ t.cudafe1.stub.c:8: error: invalid cast from type ‘const expr<boost::proto::exprns_::basic_expr<boost::proto::tag::address_of, boost::proto::argsns_::list1<expr<boost::proto::exprns_::basic_expr<boost::proto::tag::plus, boost::proto::argsns_::list2<expr<boost::proto::exprns_::basic_expr<boost::proto::tag::plus, boost::proto::argsns_::list2<expr<boost::proto::exprns_::basic_expr<boost::proto::tag::terminal, boost::proto::argsns_::term<term>, 0l> >, expr<boost::proto::exprns_::basic_expr<boost::proto::tag::terminal, boost::proto::argsns_::term<term>, 0l> > >, 2l> >, expr<boost::proto::exprns_::basic_expr<boost::proto::tag::terminal, boost::proto::argsns_::term<int>, 0l> > >, 2l> >&>, 1l> >’ to type ‘size_t’ # --error 0x1 -- The CUDA compiler works by splitting the original C++ code into "host" code and "device" code. The device code is completely lowered to C. So it seems like the above error is when passing a proto expression to the C-lowered version of device code. The proto expression is a simple POD type, so I am perplexed by the above error. (BTW, when the host compiler is gcc 4.1.3, the above program causes a segmentation fault in gcc, but that's for another forum). This might well be CUDA compiler's problem, but I dug a little deeper. I transformed the proto expression into a simpler POD type as follows : #include <boost/proto/proto.hpp> namespace proto=boost::proto; struct filler {}; template<typename tag, typename C0, typename C1=filler> struct myexpr { C0 c0; C1 c1; }; struct myadd {}; struct myterm {}; struct xform_callable : proto::callable { template<typename> struct result; template<typename This, typename LHS> struct result<This(LHS&)> { typedef myexpr<myterm, LHS> type; }; template<typename LHS> typename result<xform_callable(LHS&)>::type operator()(LHS &l) { myexpr<myterm, LHS> e = {l}; return e; } template<typename This, typename tag, typename LHS, typename RHS> struct result<This(tag, LHS, RHS)> { typedef myexpr<tag, LHS, RHS> type; }; template<typename tag, typename LHS, typename RHS> typename result<xform_callable(tag, LHS, RHS)>::type operator()(tag, LHS l, RHS r) { myexpr<tag, LHS, RHS> e = {l, r}; return e; } }; struct xform : proto::or_< proto::when<proto::plus<proto::_, proto::_>, xform_callable(myadd(), xform(proto::_left), xform(proto::_right))> , proto::when<proto::terminal<proto::_>, xform_callable(proto::_value)> > {}; template<typename> struct expr; struct domain : proto::domain<proto::pod_generator<expr> > {}; template<typename E> struct expr { BOOST_PROTO_BASIC_EXTENDS(E, expr<E>, domain) }; template<typename F> __global__ void kernel(F f) { } struct term {}; expr<proto::terminal<term>::type> a = {{{}}}; expr<proto::terminal<term>::type> b = {{{}}}; expr<proto::terminal<term>::type> c = {{{}}}; int main() { kernel<<<1,1>>>(xform()(b+c)); return 0; } The above program compiles fine with CUDA 3.2. That leaves me with the question : what does a proto expression contain more than myexpr above, that causes nvcc to fail? Again, this might be CUDA compiler's problem and they are the ones that should fix it. However, if someone in this forum can think of a simple fix to proto (or some other boost library that is actually causing the problem), that would be great too. The uniform template expansion across device and host code in CUDA programs is a powerful feature, and I envision some cool libraries that can be written using proto with CUDA. So making proto work with CUDA is a big win. Manjunath

5 12

Re: [Boost-users] [1.44 MSM meta state machine] accessing objects fromactions
by Christophe Henry 02 Nov '10

02 Nov '10

> Currently my queue object is a member of the state machine itself, so I > can write > > struct Send_ : public msm::front::state_machine_def<Send_> > { > string m_next_line_to_send; > socket m_socket; > string get_next_send_line(); > }; > > and in my a_send action > void operator()(Event &const &evt, Fsm &fsm, S&, T&) > { > fsm.m_next_line_to_send=fsm.get_next_send_line(); > fsm.m_socket.async_write(fsm.m_next_line_to_send); > } > > This works well as long as I am not using sub-statemachines. > > Here is my problem: > I would like to use a substate machine for the actual sending. The main > state machine has the states Disconnected, Working, Error, Shutdown. The > Working state should actually be a substate machine. > > The problem is, when a_send gets called by the substate machine Working, > the fsm object is of type Working. Correct. There is no "fsm call stack" yet. This gets complicated if you have a submachine of a submachine of ... For the moment I don't have this. > How can I access the member variables of the parent of a substate > machine? Or is there a better way of accessing the objects the state > machine should work with from actions? For the moment, all we can do is adding a pointer to the main fsm's data in the submachine. It is less elegant with the 1.44 than the coming 1.45: With 1.44 (for example inside the on_entry method of Send_): Send_::Working& w = fsm.get_state<Send_::Working&>(); w.data = &fsm.data; // w.data is a pointer True, this is not really nice. With the upcoming 1.45 (or trunk for the moment), you could use the new constructors: Send myfsm (msm::back::states_ << Working(data) ); //data being externally defined and Working_ having a corresponding constructor But this won't work for your case where data is contained in Send_ (and therefore does not exist at the time of construct). You can however reuse the same syntax with the new set_states method: Replace the version with get_state by: fsm.set_states(msm::back::states_ << Working(fsm.data)); //data being defined in Send_ and Working_ having a corresponding constructor. The whole explanation is there (http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#backend…) > The tutorial explains state machines very nicely with the example of a > CD player. But all the actions are empty and nowhere is explained, how > you would actually access a CD player member variable or other such > object so that you could actually manipulate the player to do something. Seems that I need to improve my doc here. It's too late for the 1.45 but I'll do it for the 1.46. I agree that this is still not perfect and it's on my list but the list is still pretty long so I hope this solution will be ok for the time being. Regards, Christophe

2 3

[Review][Ratio] Boost.Ratio has been ACCEPTED
by Anthony Williams 02 Nov '10

02 Nov '10

The following message is a courtesy copy of an article that has been posted to gmane.comp.lib.boost.devel as well. Hi, I am pleased to announce that Boost.Ratio has been ACCEPTED into Boost. There were not as many reviews for Boost.Ratio as for some libraries, but they were overwhelmingly positive. Boost.Ratio is an important building block for other upcoming submissions, and provides an implementation of the C++0x rational arithmetic facilities. A few changes were requested by the reviewers, which I will list below. I know that Vicente has already started working on some of these. These changes should be addressed before the library appears in a Boost release. * Some of the macros had names with RATIO_RATIO in. These should be changed to just RATIO * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates should derive from the resulting ratio type as well as providing the nested ::type member, in order to closely emulate the template alias facility from C++0x * The typos in the documentation should be fixed, and the documentation reviewed for correctness and clarity (though several of the reviewers made positive comments on the quality of the documentation). * The library needs more tests under the Boost Software License. * All references to names from the boost namespace should be qualified with boost:: to avoid potential name clashes and ambiguity with names from the global namespace. * Sections commented out with #if 0 should be removed * The extensions beyond the facilities required by the C++0x draft should be able to be enabled or disabled through use of a configuration macro. * References to the tests, examples and documentation from within the code should be checked for correctness. I would like to thank Vicente for submitting the library and those that took the time to write a review. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

2 1

Is it possible to use boost:serialization with Managed c++?
by سیّد امین میرزایی 02 Nov '10

02 Nov '10

We have a native c++ class that is serialized perfectly using * boost::serialization*. Now we want to change some of its member fields to *property*, so we could use them in *PropertyGrids*. When we changed the class definiction to *ref class X*, we got a huge number of these compilation errors: #1: error C2893: Failed to specialize function template 'boost::archive::text_oarchive &boost::archive::detail::interface_oarchive<Archive>::operator <<(T &)' d:\someAddress\someFile.cpp 58 #2: error C2784: 'std::basic_ostream<_Elem,_Traits> &std::operator <<(std::basic_ostream<_Elem,_Traits> &,const std::_Smanip<_Arg> &)' : could not deduce template argument for 'std::basic_ostream<_Elem,_Traits> &' from 'boost::archive::text_oarchive' d:\someAddress\someFile.cpp 58 We have a lot of tiny classes here, so it would be a pain to write a wrapper for each of them! Here is the sample class we used: ref class gps_position2 { public: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & seconds; } public: gps_position(){}; gps_position(float s) { this->seconds = s; } property float seconds; }; And here is the main test code: int main() { std::ofstream ofs("out.txt"); gps_position2 g(24.567f); // save data to archive { boost::archive::text_oarchive oa(ofs); // write class instance to archive oa << g; } // ................ return 0; } Is it even possible to use *boost::serialization* with managed classes? p.s. If we change the class usage code to this: ... gps_position2^ g = gcnew gps_position2(24.567f); ... then we get only 1 error: error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' D:\path\to\Boost\boostw\boost\archive\detail\check.hpp 60

2 1

std::string corrupt after including boost
by Simon Adler 01 Nov '10

01 Nov '10

Hello, I think the behavior of the std::string is just an example but in my application it seems to me the first stl element that is used. I have a larger project working with CLR in MC++. I included boost, because of boost::thread. Because auf the .net and CLR linking I compiled boost als shared libs and included BOOST_DYN_LINK in the preprocessor definitions. Compilation works fine. If i start the application in Debug mode i get strange behavior of my strings which results in a crash. For example an assignment like std::string test = "123"; will result in a string representation with additional malformed signs in front of the "123". I knew some behavior like this because of the Flags: #define _HAS_ITERATOR_DEBUGGING 0 #define _SECURE_SCL 0 #define _SCL_SECURE_NO_WARNINGS I usually not using them, but i have the suspicion that boost is using them and i got errors from there. Has anyone an idea what are possible solutions? Is boost introducing additional Macros that were changing the stl? Greetings Simon Adler

9 15

Boost.Regex for variable argument term?
by Joost Kraaijeveld 01 Nov '10

01 Nov '10

Hi, I am trying to make a regex that matches a term with an arbitrary number of arguments. It has the format: TERM KEY(-?PRE:COL[,-?PRE:COL]*) with at least 1 PRE:COL and at most N (comma separated) PRE:COL, each of them possible prefixe with 1 '-' char I have the following: ^([[:word:]])[[:blank:]]*KEY\$-?[[:word:]]+:[[:word:]]+(,-?([[:word:]])+:([[:word:]]+))*\$ But this does not work: e.g. the string KEY1 KEY(TEK:KDE),NOCASE,OPT,PRIMARY has the following matches (notice the empty matches): what[0] = KEY1 KEY(TEK:KDE),NOCASE,OPT,PRIMARY what[1] = KEY1 what[2] = TEK what[3] = KDE what[4] = what[5] = what[6] = and the string KEY1 KEY(RKM:KEN,RKM:REL,RKM:VAL),NOCASE,OPT,PRIMARY has the following matches (notice match 4 and the lack of the last PRE:COL pair): auxWhat[0] = KEY1 KEY(RKM:KEN,RKM:REL,RKM:VAL),NOCASE,OPT,PRIMARY auxWhat[1] = KEY1 auxWhat[2] = RKM auxWhat[3] = KEN auxWhat[4] = ,RKM:VAL auxWhat[5] = RKM auxWhat[6] = VAL Is there a regex that sort of does does what I want? TIA -- Met vriendelijke groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl

2 1

[Boost.Spirit] Skippers for sub-grammars
by Vitaly Budovski 01 Nov '10

01 Nov '10

Hello, I've decided to break up my parser into sub-grammars to improve both the readability and compile time. I'm now trying to specify a skip parser for one of the sub-grammars, but I don't know how to do it. I'm familiar with specifying a skip parser in the parse functions, but not in the grammar itself. Could somebody please provide an example? Thanks. #include <boost/spirit/include/qi.hpp> #include <string> #include <iostream> using namespace boost::spirit; using namespace boost::spirit::ascii; template<class Iterator> struct sub_grammar_skipper: qi::grammar<Iterator> { sub_grammar_skipper(): sub_grammar_skipper::base_type(start) { start = ( *((char_ - eol) - lit(':')) >> lit(':') >> *blank >> *(char_ - eol) >> eol ) ; } qi::rule<Iterator> start; }; template<class Iterator> struct sub_grammar: qi::grammar<Iterator> { sub_grammar(): sub_grammar::base_type(start) { string = ( *(char_ - eol) ) ; name %= ( lit("NAME:") >> *blank >> string >> eol ) ; start = ( name ) ; } qi::rule<Iterator, std::string()> string; qi::rule<Iterator, std::string()> name; qi::rule<Iterator> start; }; template<class Iterator> struct test_grammar: qi::grammar<Iterator/*, sub_grammar_skipper<Iterator> */> { test_grammar(): test_grammar::base_type(start) { start = ( sg >> int_ ) ; } sub_grammar<Iterator> sg; qi::rule<Iterator/*, sub_grammar_skipper<Iterator> */> start; }; int main() { std::string str("NAME: John\nBLAH: blah\n10"); typedef std::string::const_iterator iterator; iterator first = str.begin(); iterator last = str.end(); test_grammar<iterator> tg; bool r = parse(first, last, tg); if(r && first == last) { std::cout << "Success!\n"; } else { std::cerr << "Failed to parse at: " << std::string(first, last) << std::endl; return 1; } return 0; }

5 6

Re: [Boost-users] Spirit Porting
by Avi Bahra 01 Nov '10

01 Nov '10

Hartmut Kaiser wrote: >Just forget the IBM compiler. It's not up to the task to compile any of >Spirit V2 code. We talked to Michel Wong at BoostCon about this and he said >that his compiler team resources are very limited and that he does not >expect this to be fixed too soon. I was also under the impression that spirit classic would be deprecated, some time in the future, and had pencilled time to port to Spirit Qi. My main motivation for porting to QI, was the performance of spirit classic is atrocious. Currently I building on AIX and use the new IBM compiler (v11.1) but If I understand correctly you are saying dont bother trying to port from classic->Qi. ? Is it possible to provide more detailed information, about what parts of spirit Qi(I assume this is V2) the IBM compiler cant cope with ? Best regards, Ta, Avi

5 5