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

Boost.Wave getting raw input tokens for code transformation
by Frank Birbacher 30 Nov '12

30 Nov '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I'm trying to utilize Wave for simple code transformations. My starting point is to do an identity mapping through Wave: read in a source file, tokenize it, and output it again. The output shall be the same as the input on a byte by byte basis. I modified the cpp_lexer example to just output the token.value() texts. From that I discovered whitespace in "# define" will be dropped. Ok, fixed this by modifying Wave source code. Now my main problem are line continuations using backslash like in multiline macro definitions. Those get processed at a very low level, I guess. The backslash will never be reported as a token, but the adjacent characters will be fused into one token. Is there a way to define a "raw" token mode that would report the backslash and keep the adjacent characters as distinct tokens? I don't understand the tokenizer level at all. Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAlC1w/8ACgkQhAOUmAZhnmrUsQCeIVBxkYTUg1qIU2DTsSZuh5u1 2v8AniMF44HV4agBashrP81N6XN3bTW1 =A8Sp -----END PGP SIGNATURE-----

2 2

serialization of recursive objects
by kean 29 Nov '12

29 Nov '12

Hello everybody, I defined the following objects to be serialized: class MyElementObject { friend class boost::serialization::access; public: template<class Archive> void serialize(Archive & ar, const unsigned int version) { } }; template<class T> class MyRecursiveObject { friend class boost::serialization::access; public: T element; std::vector<MyRecursiveObject<T> > children; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & element; ar & children; } }; I then run the following code: int main() { //MyRecursiveObject initialization MyRecursiveObject<MyElementObject> rec_object; rec_object.children.push_back(MyRecursiveObject<MyElementObject>()); rec_object.children[0].children.push_back(MyRecursiveObject<MyElementObject>()); //create vector of pointers to MyRecursiveObject's elements vector<MyElementObject *> elt_ptrs; elt_ptrs.push_back(&rec_object.element); elt_ptrs.push_back(&rec_object.children[0].element); elt_ptrs.push_back(&rec_object.children[0].children[0].element); //serialize MyRecursiveObject and the vector of pointers { ofstream ofs("filename"); boost::archive::text_oarchive oa(ofs); oa << rec_object; oa << elt_ptrs; } //create new MyRecursiveObject and vector of pointers for deserialization MyRecursiveObject<MyElementObject> rec_object_deserialized; rec_object_deserialized.children.push_back(MyRecursiveObject<MyElementObject>()); rec_object_deserialized.children[0].children.push_back(MyRecursiveObject<MyElementObject>()); vector<MyElementObject *> elt_ptrs_deserialized; //deserialize { ifstream ifs("filename"); boost::archive::text_iarchive ia(ifs); ia >> rec_object_deserialized; ia >> elt_ptrs_deserialized; } //compare deserialized pointers cout<<"elt_ptrs first level="<<elt_ptrs_deserialized[0] <<" expected="<<&rec_object_deserialized.element<<endl; cout<<"elt_ptrs second level="<<elt_ptrs_deserialized[1] <<" expected="<<&rec_object_deserialized.children[0].element<<endl; cout<<"elt_ptrs third level="<<elt_ptrs_deserialized[2] <<" expected="<<&rec_object_deserialized.children[0].children[0].element<<endl; return 0; } And I always get an output similar to the following one: elt_ptrs first level=<b>0x7fff57c787c0* expected=*0x7fff57c787c0* elt_ptrs second level=*0x18e7020* expected=*0x18e7020* elt_ptrs third level=*0xffff8000ab5564f0* expected=*0x18e7450* As can be seen from the output I manage to deserialize pointers that point to elements down to the second recursion level of MyRecursiveObject. As soon as I try to do it with pointers to the third level or even deeper the deserialization fails. Am I using boost::serialization wrongly? Note that the MyRecursiveObject is always successfully deserialized, no matter how many levels it has. I encounter the problem only deserializing pointers to its elements. Thank you in advance Kean -- View this message in context: http://boost.2283326.n4.nabble.com/serialization-of-recursive-objects-tp463… Sent from the Boost - Users mailing list archive at Nabble.com.

2 1

Is it ok to pass &my_boost_array_variable[2] into a C function expecting a Type*
by Anton Daneyko 29 Nov '12

29 Nov '12

Hi, I have a two variables: boost::array my_boost_array_variable_1<float, 3>; boost::array my_boost_array_variable_2<float, 3>; now I want to call a C function with the following signature: int MPI_Allreduce ( void *sendbuf, void *recvbuf, ...); I want to pass the address of a particular element of my my_boost_array_variable_1 and my_boost_array_variable_2 as a first and second parameter of MPI_Allreduce: MPI_Allreduce(&my_boost_array_variable_1[2], &my_boost_array_variable_2[2], ... or should I rather do: MPI_Allreduce(my_boost_array_variable_1.c_array() + 2, my_boost_array_variable_2.c_array() + 2, ... Thanks, Anton

2 1

strange linkage problem with boost_date_time 1.52 (x86_64-linux-gnu/gcc version 4.7.2)
by mypop＠freenet.de 29 Nov '12

29 Nov '12

Hi erveryone, i have a little problem linking against my newly installed: boost_date_time library. I even don't know if this is the right place for this question because everything works fine so far in the past. 1. I never had problems compiling and linking this sources before (on 3 other systems). 2. The project also contains some other directories with some kind of commandline tools. These tools also link against the regex and date_time libraries without any problems. Here is the part where the libs are defined in my Makefile.am libmodwscmi_la_CXXFLAGS = $(INCLUDES) $(PROJECT_INCLUDES) $(APR_CFLAGS) libmodwscmi_la_LDFLAGS = $(LDADD) $(BOOST_LDFLAGS) $(LIB_BOOST_REGEX) $(LIB_BOOST_DATETIME) `$(APR1CONFIG) --link-ld --libs` libmodwscmi_la_LIBADD = $(top_builddir)/utils/mysqlpp/libmysqlpp.la $(top_builddir)/utils/jwsmtp/libjwsmtp.la After compiling is complete the linker gets called by this command: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.7/crtbeginS.o .libs/libmodwscmi_la-mod_wscmi.o .libs/libmodwscmi_la-mod_gsoap.o .libs/libmodwscmi_la-mod_utils.o .libs/libmodwscmi_la-mod_mysql.o .libs/libmodwscmi_la-md5.o .libs/libmodwscmi_la-regEx.o .libs/libmodwscmi_la-utils.o .libs/libmodwscmi_la-exception.o .libs/libmodwscmi_la-dateTime.o .libs/libmodwscmi_la-validator.o .libs/libmodwscmi_la-mysqlPool.o .libs/libmodwscmi_la-mysqlCons.o .libs/libmodwscmi_la-mysqlQueries.o .libs/libmodwscmi_la-sqlite3.o -Wl,-rpath -Wl,/var/www/projects/mod_wscmi-1.0/utils/mysqlpp/.libs -Wl,-rpath -Wl,/var/www/projects/mod_wscmi-1.0/utils/jwsmtp/.libs -L/usr/local/lib -lboost_date_time -lboost_regex -L/usr/lib /usr/lib/libapr-1.so -L/usr/local/mysql/lib ../utils/mysqlpp/.libs/libmysqlpp.so ../utils/jwsmtp/.libs/libjwsmtp.so -L/usr/lib/gcc/x86_64-linux-gnu/4.7 -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crtn.o -pthread -O3 -Wl,-R/usr/local/lib -pthread -Wl,-soname -Wl,libmodwscmi.so.0 -o .libs/libmodwscmi.so.0.0.0 As you can see above, both libraries are present: -lboost_date_time -lboost_regex. They also can be found on the harddrive (in /use/local/lib): ... -rw-r--r-- 1 root 136876 Nov 20 09:19 libboost_date_time.a lrwxrwxrwx 1 root 28 Nov 20 09:18 libboost_date_time.so -> libboost_date_time.so.1.52.0 -rwxr-xr-x 1 root 94337 Nov 20 09:18 libboost_date_time.so.1.52.0 ... -rw-r--r-- 1 root 2619610 Nov 20 09:19 libboost_regex.a lrwxrwxrwx 1 root 24 Nov 20 09:18 libboost_regex.so -> libboost_regex.so.1.52.0 -rwxr-xr-x 1 root 1251576 Nov 20 09:18 libboost_regex.so.1.52.0 ... The complete build runs fine! There are no errors or warnings but the fianlly library is unusable because: boost_date_time is not present. Ldd shows up something like this: ldd .libs/libmodwscmi.so.0.0.0 linux-vdso.so.1 => (0x00007fff17da4000) libboost_regex.so.1.52.0 => /usr/local/lib/libboost_regex.so.1.52.0 (0x00007ff289006000) libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007ff288db5000) libmysqlpp.so.0 => /var/www/projects/mod_wscmi-1.0/utils/mysqlpp/.libs/libmysqlpp.so.0 (0x00007ff288b35000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff288832000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff288472000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff28825c000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff28803f000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007ff287e39000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff287c35000) libmysqlclient.so.18 => /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18 (0x00007ff2876f1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff2873f4000) /lib64/ld-linux-x86-64.so.2 (0x00007ff2895e9000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff2871dd000) Only libboost_regex.so.1.52.0 was linked in and i have absolutly no idea why: libboost_date_time does not show up. So maybe someone of the list can give me an adivse of what's is going on here. Thanks and greetings Michael --- E-Mail ist da wo du bist! Jetzt mit freenetMail ganz bequem auch unterwegs E-Mails verschicken. Am besten gleich informieren unter http://mail.freenet.de/mobile-email/index.html

3 3

Fwd: [boost] [thread] Crash when calling pthread_cond_wait from thread.cpp in iOS simulator
by Brent Lewis 29 Nov '12

29 Nov '12

I've determined that pthread_cond_wait works fine on an iPhone (hardware) and works fine when called from my own module on simulator (I use boost::condition_variable, and since it's header only and calling pthread_cond_wait, it's my module) But when I create a new thread, which goes through thread.cpp in the thread library, call_once in once.hpp has to (sometimes, based on synchronization randomness) call pthread_cond_wait which results in the message: Detected an attempt to call a symbol in system libraries that is not present on the iPhone: (null) called from function _ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_ in image Blackjack If I make it continue, I get a problem report from OSX which tells me that the stack trace is: 0 libsystem_kernel.dylib 0x903a5a6a __pthread_kill + 10 1 libsystem_c.dylib 0x96afbacf pthread_kill + 101 2 libsystem_sim_c.dylib 0x03a0457b abort + 140 3 libSystem.dylib 0x032ad4ad _interposition_vtable_unimplemented + 200 4 libSystem.dylib 0x032c0938 pthread_cond_wait$UNIX2003 + 60 5 Blackjack 0x00277c8c void boost::call_once<void (*)()>(boost::once_flag&, void (*)()) + 156 (once.hpp:112) 6 Blackjack 0x0027506b thread_proxy + 139 (thread.cpp:135) 7 libsystem_c.dylib 0x96afa557 _pthread_start + 344 8 libsystem_c.dylib 0x96ae4cee thread_start + 34 Is it maybe some discrepancy in the settings I'm using to build boost that's causing to link something wrong... something else? I've attached the complete crash log. In case it is build related, this is how I've built boost using a shell script: LIBS=" --with-thread --with-serialization --with-date_time" CPLUS_INCLUDE_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneOS6.0.sdk/usr/include/ PATH=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:$PATH ./b2 toolset=darwin runtime-link=static link=static variant=release include=$CPLUS_INCLUDE_PATH cxxflags=--visibility=default cxxflags=-Wno-long-long --build-dir=$HOME/boost/lib/build --includedir=$HOME/boost/include --libdir=$HOME/boost/lib/build/arm-release architecture=arm target-os=iphone $LIBS -q install

1 0

[counting_range] why?
by Robert Jones 28 Nov '12

28 Nov '12

Ok, maybe I'm having a senior moment here, but why is the second line wrong? Thx, Rob. #include <boost/range/counting_range.hpp> int main( ) { // Ok auto r = boost::counting_range( 0, 3 ); // Not Ok. auto s = boost::counting_range<int>( 0, 3 ); }

3 6

[graph] File Dependency Example with updates
by Brian Budge 28 Nov '12

28 Nov '12

Hi all - I am toying around with the file dependency example that is part of the boost graph documentation as a way of adapting the concepts to my own use cases. What I want to do is update the graph over time (add more files with more dependencies), and incrementally decide what needs to be built, and in what order. It makes sense that doing a breadth-first search from a changed node will give me everything that might be affected; however, if I change many nodes, is there something better? I could imagine that I might mark nodes as they are encountered so that other BFS from other changed nodes won't traverse those as well. With boost graph, how can I control the BFS to stop recursion if a vertex has already been visited? I guess then once I have seen all the stale vertices, I can make a smaller graph that only has the stale vertices and their connections, and I can topologically sort the sub-graph to find the parallel build order? Sorry, I'm a bit out of practice with my graph algorithms in general, and I'm very new to the boost graph library, so I hope I haven't said anything dumb :) Any design suggestions welcome. Thanks, Brian

2 6

Re: [Boost-users] [Who's using boost?] Algocoders : books on c++11, Boost and Beyond
by Erika James 27 Nov '12

27 Nov '12

On 28 November 2012 02:53, Algocoders . <algocoders(a)gmail.com> wrote: > > It is the pioneering efforts at boost towards "Using and Extending C++11, > Boost and Beyond" which has motivated us to devote ourself in developing > bullet-size capsules in the form of tiny booklets with industrial-set > framework to lift the thin veil with initial focus on practical usage of > C++11 vis-a-vis mathematical foundation behind it. > Wow, that's quite a mouthful! I read the excerpt of your first book on the website, and particularly enjoyed the final paragraph: *One thing was very much clear that, the naive looking interface* *was mere a rosy picture, hiding many unpleasant surprises in its bosom,* *which we thought of unfathoming it to its fullest. * I've never heard a C++ interface described as a bosom! I think you should rename the book to "Fifty shades of Boost"! ~Erika

1 0

[Review] Review results for Coroutines
by Hartmut Kaiser 24 Nov '12

24 Nov '12

All, The review for the Coroutines library written by Oliver Kowalke started September 3rd 2012, and ended on September 12th 2012. I counted 7 votes, none of which were NO. All authors votes YES, some made additional requests. Overall, the verdict of the community was clear: Oliver Kowalke's Coroutines library is ACCEPTED The discussion was lively and it touched on several points. Design ------ The Coroutines library offers enormous potential for programming regimes such as communications software and embedded systems design. Oliver selected a sensible granularity for his design. This granularity allows for fine-tuning the implementations of cooperative scheduling mechanisms while avoiding the prohibitively heavy weight of preemptive scheduling that is found in POSIX and often in implementations of the C++11 thread support library. In particular, the separation of Coroutines from Context allows for porting to other systems with minimal effort and maximum reliability and code re-use. Some suggestion related to the API have been made during the review, most of which (if not all) have already been addressed. Oliver has a full list of things and works on integrating the suggestions. Here is a short list: - allow to specify the allocator to use for memory allocations inside the library - remove 'self' pointer and replace with TLS - add symmetric coroutines API - better support for generator functionality Naming ------ Some of the people participating in the discussions suggested not to use the abbreviated 'namespace coro', but to use the full 'namespace coroutines' instead. This again is not a precondition for acceptance. Documentation ------------- The consensus of almost everybody referring to the documentation was that it is terse but readable and sufficient. People suggested to integrate the docs of the old Coroutines library (written as an GSoC project by Giovanni P. Deretta) into the documentation of the reviewed library. I would like to thank all who participated in the discussions. Regards Hartmut --------------- http://www.cct.lsu.edu/~hkaiser http://stellar.cct.lsu.edu http://boost-spirit.com

1 0

Re: [Boost-users] [Range & c++0x Lambdas] Can this be done?
by John M. Dlugosz 24 Nov '12

24 Nov '12

------------------------------ Message: 3 Date: Thu, 22 Nov 2012 11:31:05 -0800 From: "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung(a)gmail.com> To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Range & c++0x Lambdas] Can this be done? Message-ID: <CANvXPuQmePirYFadBKRyVoQur1N8DH2c-QhwqHgZMV2MNfG_gQ(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" > Maybe this is what you did, so I might not be suggesting something new, > but... Perhaps boost::result_of could have an extra conditional logic > branch added to it: I don't recall the details, but I've learned that result_of has compatibility issues with old/new ways in general. So, if the "old way" is published at all, use it (for backward compatibility, in case it is different from what decltype would detect). This allows lamdas and other code that assumes decltype is being used, while preseving the behavior of code that explicitly publishes the type. > - If F::result_type exists, return F::result_type; > - Else: << same as before >> Meanwhile, for different reasons, I made a macro that abstracts the >> different syntax between C++11 lambdas and Apple Block Closures. The latter >> generates a suitable lambda class complete with result_of member. That >> makes me think that you could have a macro that wraps a compiler-generated >> lambda expression in another class that inherits the operator() etc. and >> adds in the result_of typedef to simply use decltype. >> > Wouldn't that require defining a class at expression scope? Is that > possible? > > - Jeff > Here's my docs on the matter: Given a macro M, at its simplest M can expand to either [=] or ^ depending on the platform, and then be followed by the optional lambda-declarator and compound-statement. However, Apple's Blocks do not have proper value semantics. You must call a function on it before leaving the scope where it was defined, if it is to be used outside of that scope. And then it needs to be explicitly destroyed when it is no longer needed. In order to use it transparently in C++, it needs to be wrapped in an object with a destructor, (and that wrapper can take care of the initial function call too). But we don't want to have to inject anything _after_ the compount-statement, or the macro syntax would be difficult, requiring either fully-bracketing macros or double parens around the whole thing. Meanwhile, the wrapper object needs to be templatized to provide the correct typed operator() forwarding function. My (JMD's) solution is to use an operator, which can take a second argument as trailing text without being wrapped in parens. That is, M would expand to dummy| ^ so that after the trailing text (not seen by the macro) you get: dummy| ^(ARGLIST){BLOCK} that is, the completed Apple Block Literal Expression becomes the second argument of the operator|, and my special object is the first argument. The operator| can be a template, and break open the Block type in the same manner as can be done for normal function pointer declarations. For wrapping a C++ lambda, reason is different (add the decltype) but you still return an instance of a class with the right stuff in it. The return value is a templated type, wrapper0<Ret>, wrapper1<Ret,A1>, or wrapper2<Ret,A1,A2> (etc) (an emulation of "..." for some fixed number of arguments) So, the _type_ is not unique, but reused for each time the same operator() is needed. The instance holds the underlying (wrapped) instance as a member. For Apple Blocks, that is just their variation on a function pointer, so the type goes with the signature. To wrap C++11 lamdas, the underlying instance has a unique type. So use _that_ as the template argument, and generate another unique type that you can inherit from. Using an operator| to add the wrapper, you can explicitly pull it in when needed along with any other filters that are being applied.

1 0