June 2013 - Boost - lists.boost.org

Re: [boost] [utility][thread] result_of - erroneous result type from a C++11 lambda
by Klaim - Joël Lamotte 04 Jul '13

04 Jul '13

On Tue, Apr 2, 2013 at 7:16 PM, Vicente J. Botet Escriba < vicente.botet(a)wanadoo.fr> wrote: > I've started to use C++11 lambda functions with Boost.Thread. > > The following works with clang-3.2 > > boost::future<int> f1 = boost::async( []() -> int {return 123;} ); > > > But it fails with gcc-4.6.2, 4.7.2 and 4.8.0 > > ../example/lambda_future.cpp:**25:91: erreur: conversion from > ‘boost::future<void>’ to non-scalar type ‘boost::future<int>’ requested > boost::future<int> f1 = boost::async( []() -> int {return 123;} ); > > The current implementation of boost::async uses boost::result_of to get > the result type of the callable parameter. > > Is this a know bug on boost::result_of or gcc compiler? > I'm seeing exactly the same behaviour in *VS2012 Update 2*. I'm using Boost 1.54.0 beta *r84748* To be more precise: 1) I first was just using boost::future and tried to use the new .then(), here is a full repro: #include <boost/thread/future.hpp> auto ft = boost::async( []{ return 42; } ).then( []( boost::future<int> r ){ return 666; } ); This fails because boost::async() returned a future<void> instead of a future<int>. I suspect the then() call to have the same problem. I can provide the full error log but I think it's not that useful. 2) Just to be sure I tried this full test: #include <boost/thread/future.hpp> int main() { auto ft = boost::async( []{ return 42; } ); // SUCCEED: static_assert( std::is_same< decltype(ft), boost::future<void> >::value, "WTF???" ); // FAILS: static_assert( std::is_same< decltype(ft), boost::future<int> >::value, "Not the expected type!" ); } Both asserts confirm that I don't get what I want. 3) I remembered that there were some issues from usage of boost::result_of in Boost.Log, so to clarify the situation I setup the following full test: #include <boost/utility/result_of.hpp> #include <type_traits> int top() { return 42; } struct K { int operator()(){ return 42; } typedef int value_type; }; auto F = []{ return 42; }; int main() { // A: ALL SUCCEED static_assert( std::is_same< decltype(K()()), int >::value, "Not the expected type!" ); static_assert( std::is_same< decltype(top()), int >::value, "Not the expected type!" ); static_assert( std::is_same< decltype(F()), int >::value, "Not the expected type!" ); // B: ALL SUCCEED static_assert( std::is_same< std::result_of<K()>::type, int >::value, "Not the expected type!" ); static_assert( std::is_same< std::result_of<decltype(top)>::type, int >::value, "Not the expected type!" ); static_assert( std::is_same< std::result_of<decltype(F)()>::type, int >::value, "Not the expected type!" ); // C: ALL SUCCEED std::result_of<K()>::type a = K()(); std::result_of<decltype(top)>::type b = top(); std::result_of<decltype(F)()>::type c = F(); // D: ALL FAILS static_assert( std::is_same< boost::result_of<K()>::type, int >::value, "Not the expected type!" ); static_assert( std::is_same< boost::result_of<decltype(top)>::type, int >::value, "Not the expected type!" ); static_assert( std::is_same< boost::result_of<decltype(F)()>::type, int >::value, "Not the expected type!" ); // E: ALL FAILS boost::result_of<K()>::type d = K()(); // error C2182: 'd' : illegal use of type 'void' boost::result_of<decltype(top)>::type e = top(); // error C2182: 'e' : illegal use of type 'void' boost::result_of<decltype(F)()>::type f = F(); // error C2182: 'f' : illegal use of type 'void' } This shows clearly that: 1. boost::result_of don't behave like std::result_of on this platform (and from previous discussions, on other platforms too). 2. both std::result_of and decltype() provide the result I expect from reading documentations about these. So far I'm assuming that the problem really is from boost::result_of, but I might be wrong because the differences with std::result_of are not clear to me. ---- Unfortunately this makes future.then() unusable if we expect return types. I don't know if it impacts other libraries (I suspect Boost.Log). Should I report a bug or is it known, already fixed or a misuse? Joel Lamotte

5 12

[result_of] Documentation update for ticket 7753
by Nathan Crookston 03 Jul '13

03 Jul '13

Hi Daniel & all, I'm updating the patch for ticket 7753 ( https://svn.boost.org/trac/boost/ticket/7753) I've made the requested changes to the patch, but I had a question on how to best explain which macro to define if, for example, you want result_of to work with C++11 lambdas. In the past, users with a pre-N3276 decltype have been advised to just #define BOOST_RESULT_OF_USE_DECLTYPE, with the explanation that "it's probably just going to work." While that advice is true, there are cases where this doesn't work; hence the addition of BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK. To explain why you'd define the FALLBACK macro over the USE_DECLTYPE macro, I'm thinking of including a paragraph like the following. "The question naturally arises on why have both BOOST_RESULT_OF_USE_DECLTYPE and BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK. In many situations, BOOST_RESULT_OF_USE_DECLTYPE will work well, even with pre-N3276 decltype. However, there are cases where a post-N3276 decltype is required to correctly deduce the return type of a functor. If a translation unit includes a functor whose return type is only deducible with TR1 or a post-N3276 decltype, using result_of with, e.g. a C++11 lambda function, will fail without BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK. If the macro BOOST_NO_CXX11_DECLTYPE_N3276 is defined and BOOST_NO_CXX11_DECLTYPE is not defined when including result_of.hpp, defining BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK is the safest option that will allow you to deduce C++11 lambda return types." My question is, am I over explaining it? Of course, I'd rather have BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK defined automatically for compilers like VC10, g++4.5, etc., and include text like the following: "If you rely on the result of calling a nullary functor to be void, regardless of the actual return type, or if your code is not written to handle cases other than BOOST_RESULT_OF_USE_TR1 and BOOST_RESULT_OF_USE_DECLTYPE, you may wish to explicitly define one of those symbols prior to including result_of." Either way, comments welcome. Thanks, Nate

3 4

[Serialization] Constructor for polymorphic archives
by Bjorn Reese 03 Jul '13

03 Jul '13

I have a set of my own Boost.Serialization archives (e.g. [1]) that I wish to write polymorphic variants of. I have tried to follow the blueprint from polymorphic_text_iarchive, which inherits from polymorphic_iarchive_route. The problem is that the constructor of my archives takes iterators (begin and end) as arguments, but the polymorphic_iarchive_route constructor expects a std::stream argument. Is there any workaround for this? [1] http://sourceforge.net/p/protoc/code/ci/master/tree/include/protoc/transenc…

3 4

Any interest in bitstream class?
by Paul Long 02 Jul '13

02 Jul '13

Same semantics as, e.g., stringstream, but it operates on binary data. I already have the analogues to istringstream/stringbuf (you can take a look at ibitstream/bitbuf at https://github.com/dplong/bstream) There are some interesting features, but I won't go into them here. If there is interest, I would implement obitstream and bitstream and possibly support Boost::dynamic_bitset. The rationale is _succinct_ expression of predictive parsing of binary data. I've used ibitstream in production code for decoding RTP headers and frames of various video encodings. Below is a simple function that decodes an RTP header using ibitstream; I also have a GitHub repo that contains more complex code for high-level parsing of H.264 frames at https://github.com/dplong/rtspudph264 struct RtpHeader { bool padding, marker; bitset<7> payloadType; WORD sequenceNumber; DWORD timestamp, ssrcIdentifier; vector<DWORD> csrcIdentifier; struct { bool present; WORD identifier; vector<BYTE> contents; } extension; }; bool ParseRtpHeader(const BYTE *buffer, RtpHeader &rtp) { ibitstream bin(buffer); static const bitset<2> version(0x2); bitset<4> csrcCount; WORD extensionLength; bin >> version >> rtp.padding >> rtp.extension.present >> csrcCount >> rtp.marker >> rtp.payloadType >> rtp.sequenceNumber >> rtp.timestamp >> rtp.ssrcIdentifier >> setrepeat(csrcCount.to_ulong()) >> rtp.csrcIdentifier; if (rtp.extension.present) { bin >> rtp.extension.identifier >> extensionLength >> setrepeat(extensionLength * sizeof(DWORD)) >> rtp.extension.contents; } return bin.good(); }

10 47

Static initialization of boost shared objects question
by Juan Carlos Franzoy 02 Jul '13

02 Jul '13

Hello. Thanks for reading my question. I fell into a deadlock in static initialization of boost shared objects. The deadlock occurs in a reentrant call to a function which contains a definition of a static variable. Apparenlty gcc protects the initialization of such variables with a condition variable. Looking at the c++ code nothing at all make anybody suspect about reentrancy. My "interpretation of the fact" may be titled 'something in gcc, ld, ld.so, c++language made the call to be reentrant' - There is a function boost::system::generic_category() that has a static variable V - V type is boost::system::annonymous-namespace::generic_error_category - boost::system::annonymous-namespace::generic_error_category is subclass of boost::system::error_category. - boost::system::annonymous-namespace::generic_error_category has no declared/defined constructor as well as all its superclasses - The compilation process generate the constructor boost::system::error_category::error_category() as a weak symbol inside every shared object that uses it. - There is a static variable boost::system::posix_category in one of the shared objects that is initialized calling boost::system::generic_category(). - when the static initialization of a shared object boost::system::posix_category get initialized - which calls boost::system::generic_category() - Inside boost::system::generic_category() starts the initialization of V which calls boost::system::error_category::error_category() - It may happend that the runtime calls an instance of boost::system::error_category::error_category() that resides in a shared object that is still not loaded - So that .so get loaded and it is called its own static initialization - which can call boost::system::generic_category() - BOOM I would love if you can confirm of refute my humble "interpretation". Details follows ------------------- boost version: 1-52-0 Operating system: uname -a SunOS bcpp-solaris10 5.10 Generic_147441-25 i86pc i386 i86pc $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/local/gcc-4.6.2/libexec/gcc/i386-pc-solaris2.10/4.6.2/lto-wrapper Target: i386-pc-solaris2.10 Configured with: ../src/gcc-4.6.2/configure --prefix=/export/home/local/gcc-4.6.2 --with-gmp=/export/home/local/gcc-4.6.2/gmp-4.3.2 --with-mpfr=/export/home/local/gcc-4.6.2/mpfr-3.0.0 --with-mpc=/export/home/local/gcc-4.6.2/mpc-0.8.2 --with-libelf=/export/home/local/gcc-4.6.2/libelf-0.8.12 --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --enable-languages=c,c++ --with-as=/usr/local/bin/as --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-plugin --enable-multilib --enable-version-specific-runtime-libs --enable-bootstrap --enable-ssp --enable-libssp --with-included-gettext --enable-lto --host=i386-pc-solaris2.10 --build=i386-pc-solaris2.10 Thread model: posix gcc version 4.6.2 (GCC) Callstack backtrace (lines begining with = are my comments): = = deadlock here: the threads is waiting itself = #0 0xfd459019 in __lwp_park () from /lib/libc.so.1 #1 0xfd45365e in cond_sleep_queue () from /lib/libc.so.1 #2 0xfd453817 in cond_wait_queue () from /lib/libc.so.1 #3 0xfd453b94 in cond_wait_common () from /lib/libc.so.1 #4 0xfd453d02 in _cond_wait () from /lib/libc.so.1 #5 0xfd453d2d in cond_wait () from /lib/libc.so.1 #6 0xfd453d66 in pthread_cond_wait () from /lib/libc.so.1 #7 0xfd632898 in __gthread_cond_wait (g=0xfd822ea8) at ...build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/i386-pc-solaris2.10/bits/gthr-default.h:846 #8 __gthread_cond_wait_recursive (g=0xfd822ea8) at ...work/build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/i386-pc-solaris2.10/bits/gthr-default.h:860 #9 __gnu_cxx::__cond::wait_recursive (g=0xfd822ea8) at ...build-gcc/out/i386-pc-solaris2.10/libstdc++-v3/include/ext/concurrence.h:377 #10 __cxa_guard_acquire (g=0xfd822ea8) at .../src/gcc-4.6.2/libstdc++-v3/libsupc++/guard.cc:289 = = Reentrant call to boost::system::generic_category() = #11 0xfd812313 in boost::system::generic_category () at libs/system/src/error_code.cpp:425 #12 0xfe85cd38 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/system/error_code.hpp:214 #13 0xfe85d05f in _GLOBAL__sub_I_instantiate_re2c_lexer_str.cpp () at libs/wave/src/instantiate_re2c_lexer_str.cpp:56 = = static initization of boost.wave library = #14 0xfe8868fd in __do_global_ctors_aux () from ...boost/lib/libboost_wave-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #15 0xfe88692a in _init () from ...boost/lib/libboost_wave-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #16 0xfefce37e in call_init () from /usr/lib/ld.so.1 #17 0xfefce1cf in is_dep_init () from /usr/lib/ld.so.1 #18 0xfefdaa4b in elf_bndr () from /usr/lib/ld.so.1 #19 0xfefc2ab4 in elf_rtbndr () from /usr/lib/ld.so.1 #20 0xfee60688 in ?? () #21 0xfee0c8f6 in boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_alloc_>() at ./boost/exception/detail/exception_ptr.hpp:119 #22 0xfee0c0d2 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/exception/detail/exception_ptr.hpp:138 #23 0xfee0c271 in _GLOBAL__sub_I_future.cpp () at libs/thread/src/future.cpp:60 = = static initization of boost.thread library = #24 0xfee0d98d in __do_global_ctors_aux () from ...boost/lib/libboost_thread-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #25 0xfee0d9ba in _init () from ...boost/lib/libboost_thread-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #26 0xfefce37e in call_init () from /usr/lib/ld.so.1 #27 0xfefce1cf in is_dep_init () from /usr/lib/ld.so.1 #28 0xfefdaa4b in elf_bndr () from /usr/lib/ld.so.1 #29 0xfefc2ab4 in elf_rtbndr () from /usr/lib/ld.so.1 #30 0xfdce0688 in ?? () = = First calll to boost::system::generic_category() = #31 0xfd81232a in boost::system::generic_category () at libs/system/src/error_code.cpp:425 #32 0xfd812386 in __static_initialization_and_destruction_0(__initialize_p=1, __priority=65535) at ./boost/system/error_code.hpp:214 #33 0xfd8123ed in _GLOBAL__sub_I_error_code.cpp () at libs/system/src/error_code.cpp:430 = = static initialization of boost.system = #34 0xfd8126ed in __do_global_ctors_aux () from ...boost/lib/libboost_system-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #35 0xfd81271a in _init () from ...boost/lib/libboost_system-gcc46-mt-d-32-SOLARIS-X86-1_52.so.1.52.0 #36 0xfefce37e in call_init () from /usr/lib/ld.so.1 #37 0xfefcd7d5 in setup () from /usr/lib/ld.so.1 #38 0xfefdba3e in _setup () from /usr/lib/ld.so.1 #39 0xfefc299c in _rt_boot () from /usr/lib/ld.so.1 #40 0x08047540 in ?? () #41 0x08047670 in ?? () More thanks for reading all.

3 4

[range] Time to merge Oven-to-Boost Extensions?
by Michel Morin 30 Jun '13

30 Jun '13

Hi, IIRC, the formal review is not necessary for the merge of Akira's Oven-to-Boost Extensions; only the range authors' review/permission are necessary. Neil, Nate, could we merge the extensions in the near future? I think everyone wants * `dropped` adaptor * `elements` adaptor * `taken` adaptor * `regular` utility so merging these first (and eventually merging the rest) would make the users happy. Regards, Michel

4 4

Re: [boost] Any interest in bitstream class?
by Brian Wood 30 Jun '13

30 Jun '13

From: Rob Stewart > On Jun 28, 2013, at 6:50 PM, Paul Long <plong(a)packetizer.com> wrote: > >> Correct, but it is important to note that integrals are always encoded big endian in the bitstream. I >>suppose it's possible that someone would want some other endian, but that's got to be an obscure use >>case. > > There are plenty of little endian only contexts that would want to avoid the host->network->host > conversions for all transfers. The C++ Middleware Writer uses a "receiver makes right" approach to support that. There's a SameFormat class here: http://webEbenezer.net/misc/Formatting.hh that's used when both sides have the same endian-ness. -- Brian Ebenezer Enterprises - Was Eisenhower the last decent US President? http://webEbenezer.net

2 1

Re: [boost] [Boost-users] Herb Sutter on C++ Standardization and Visual Studio
by Nathan Ridge 30 Jun '13

30 Jun '13

> Herb Sutter on C++ Standardization at Microsoft. > > http://channel9.msdn.com/Events/Build/2013/2-306 > > SGL Pretty good news, IMO. In addition to the C++11 and C++14 plans, Herb announced that Microsoft would complete the holes in their C++98 standard support by finally fixing their preprocessor and implementing correct two-phase name lookup (39:18 in the video). Perhaps the last discussion about these things [1] helped to tip the scale. In any case, I'm glad to hear it. Regards, Nate [1] http://boost.2283326.n4.nabble.com/C-announcements-coming-tomorrow-td463790…

1 0

boost::thread dependency on boost::chrono (windows implementation)
by Christian Hägele 28 Jun '13

28 Jun '13

Hello, as boost::thread now depends on boost::chrono I have the following questions: In boost::chrono on windows the the steady_clock is implemented via QueryPerformanceCounter. This may lead to wrong results because on some systems QueryPerformanceCounter gives different results on different processors. In our software we encountered theses problems regularly on some customers machines and thus stopped using QueryPerformanceCounter without additional checking. The problem I'm talking about is described as a TODO in boost/chrono/system_clocks.hpp My questions is if functions like boost::thread::timed_join or boost::mutex::timed_wait may have similar problems on hardware where QueryPerformanceCounter gives wrong result. Is there a way (like a preprocessor macro) to have boost::thread use the old implementation independent from boost::chrono? Regards, Christian

8 10

[1.54.0] Release candidates available
by Marshall Clow 28 Jun '13

28 Jun '13

Release candidate files for 1.54.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: efbfbff5a85a9330951f243d0a46e4b9 *boost_1_54_0_rc1.tar.gz 15cb8c0803064faef0c4ddf5bc5ca279 *boost_1_54_0_rc1.tar.bz2 78a35834c45220a6164310e280abe675 *boost_1_54_0_rc1.zip 89e734ffd2afe0982b2d9fc21d033dba *boost_1_54_0_rc1.7z Thanks! -- The release managers

6 9

Re: [boost] Could the custom allocator for flyweight hashed_factory be the boost::interprocess::allocator?
by JOAQUIN M. LOPEZ MUÑOZ 28 Jun '13

28 Jun '13

H Jin, ________________________________________ De: Boost [boost-bounces(a)lists.boost.org] en nombre de Jin Chen [chenjin92(a)gmail.com] Enviado el: lunes, 24 de junio de 2013 19:56 Para: Boost(a)lists.boost.org Asunto: [boost] Could the custom allocator for flyweight hashed_factory be the boost::interprocess::allocator? > I want to use boost::flyweight to do the dedupilcation of > boost::interprocess::basic_string object. I wrote a small test program for > that. In my program: > The flyweight works fine with the interprocess::basic_string which uses the > interprocess::allocator only with the default hashed_factory. The default > hashed_factory is ideal except that it uses std::allocator instead of > interprocess::allocator. I followed the > http://www.boost.org/doc/libs/1_53_0/libs/flyweight/doc/tutorial/configurat… > specifier > of a custom hash_factory which can change its allocator to the interprocess > one, but then got insanely long compiler error that is super hard to > decode... This is a very interesting exercise! There are several problems with your solution: * First of all, hashed_factory, as Jonathan points out, assumes the allocator is default constructible. As boost::interprocess::allocator needs a segment manager at construction time, you can overcome this by writing a custom interprocess allocator that takes that info statically, i.e., from a type that returns the segment manager: struct memory_dat_segment_manager { typedef ipc::managed_mapped_file::segment_manager type; static type* get() { static ipc::managed_mapped_file* segment= new ipc::managed_mapped_file(ipc::open_or_create,"memory.dat",409600); return segment->get_segment_manager(); } }; template<typename T,typename SegmentManager> struct segment_allocator: boost::interprocess::allocator<T,typename SegmentManager::type> { typedef boost::interprocess::allocator<T,typename SegmentManager::type> super; segment_allocator():super(SegmentManager::get()){} template<typename T2> segment_allocator(const segment_allocator<T2,SegmentManager>& x):super(x){} super& base(){return *this;} template<typename T2> struct rebind{ typedef segment_allocator<T2,SegmentManager> other; }; friend void swap(segment_allocator& x,segment_allocator& y) { swap(x.base(),y.base()); } }; Note that segment_allocator is default constructible: the segment is created on the first call to memory_dat_segment_manager. * Now, the holder class (www.boost.org/libs/flyweight/doc/tutorial/configuration.html#holders ) needs also to place its content in shared memory. As none of the holders provided by Boost.Flyweight does this, we must define our own: template<typename SegmentManager,typename C> struct segment_holder_class:boost::flyweights::holder_marker { static C& get() { static C* pc=SegmentManager::get()-> find_or_construct<C>(typeid(segment_holder_class).name())(); return *pc; } }; template<typename SegmentManager> struct segment_holder:boost::flyweights::holder_marker { template<typename C> struct apply { typedef segment_holder_class<SegmentManager,C> type; }; }; Again, the holder uses a SegmentManager class to get access to the segment manager * Finally, you need an interprocess locking policy (www.boost.org/libs/flyweight/doc/tutorial/configuration.html#locking ), and again this needs to be custom-defined (note that, in order for labeled_recursive_mutex to be default constructible, we get the info needed at construction time (the name of the mutex) from a Name class much in the same way we did with SegmentManager before for the allocator and holder): template<typename Name> struct labeled_recursive_mutex { typedef boost::interprocess::named_recursive_mutex mutex_type; operator mutex_type&() { static mutex_type mutex( boost::interprocess::open_or_create,Name::get()); return mutex; } }; template<typename Name> struct labeled_locking:boost::flyweights::locking_marker { typedef labeled_recursive_mutex<Name> mutex_type; typedef boost::interprocess::scoped_lock< typename labeled_recursive_mutex<Name>::mutex_type> lock_type; }; There's a technical issue here (if you don't get the following explanation you might as well skip it): As the mutex used by Boost.Flyweight is created by the holder class and we are using a shared-memory custom holder, it turns out labeled_recursive_mutex is thus created in shared memory. But boost::interprocess::named_recursive_mutex cannot be created in shared memory: we solve the problem with operator mutex_type&(), which actually creates the real mutex as a static variable in regular memory. And we're done. Find attached a small complete program showing how to put all the pieces together. Best, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

2 1

[Spirit] Retrieve informations out of tokens
by ... ... 27 Jun '13

27 Jun '13

Hi, I want to create a c++ syntax analysor (for creating auto-completion tools), and to help me, I want to use the boost.spirit library. In order to learn the basics of spirit, I executed this exercise. It is now working but I want to display the tokens' characters instead of counting tokens. The problem is I don't know the properties of the argument passed to my functor (the variable "t" in the code below). What is the type of this variable and what are the public method/attributes we can use on ? This is the code of my functor : struct counter{ counter() : j(0) {j = new int();} counter(const counter &model) : j(model.j) {} ~counter() {delete int;} template <typename Token> bool operator()(Token const& t){//I want to know the type of this variable t ++i; ++(*j); std::ostringstream oss; oss << "global : " << i << " membre : " << *j;//typeid(t).name(); printf("%s\n", oss.str().c_str()); return true; } int* j;}; The variable t will be relay to my functor by the following tokenize function : counter* foncteur = new counter();lex::tokenize(first, last, word_count_functor, *foncteur); I still have other questions : I read a consistent part of the documentation but I have not been able to define the type of regex used by boost.spirit. Which type is it ? What is the more appropriate function to use to analyse c++ synthax : tokenize or tokenize _and_parse ? You seems to describe tokenize_and_parse as a more powerful tool, but is it possible to define all the syntax of c++ using a parser ? Could I find an example of c++ syntax analysor using boost.spirit ? Any help would be appreciate,Cordialy,Guillaume Bersac237bis rue de Pessac33000 Bordeaux06.65.30.89.43

6 11

Interest in an 'either' library?
by David Sankel 26 Jun '13

26 Jun '13

**semantics**: template< typename left_type, typename right_type> struct either { // postcondition, is_left() either( left_type ); // postcondition, is_right() either( right_type ); bool is_left() const; bool is_right() const; // postcondition, is_left() either & operator=( left_type ); // postcondition, is_right() either & operator=( right_type ); // precondition, is_left() left_type left(); // precondition, is_right() right_type right(); private: }; **uses**: **Use 1**: Can be used as an alternative to exceptions or the (error codes+set reference idiom): either<error_code, file_id> load_file(...); vs. error_code load_file( file_id &, ... ); or // throws std::exception file_id load_file(...); **Use 2**: A lightweight alternative to boost::variant when only 2 components are required (either relates to variant in a similar way that pair relates to tuple ). variant<A,B> eitherAOrB; if( A * aPtr = boost::get<A>( &eitherAOrB ) ) std::cout << "A: " << *aPtr; else std::cout << "B: " << boost::get<B>( eitherAOrB ); vs. either<A,B> eitherAOrB; if( eitherAOrB.is_left() ) std::cout << "A: " << eitherAOrB.left(); else std::cout << "B: " << eitherAOrB.right(); --David Sankel

12 41

[1.54.0] Release notes
by Daniel James 26 Jun '13

26 Jun '13

Hello everyone, It's time to send me your release notes, or if you're feeling enthusiastic, you can add them yourself at: http://svn.boost.org/svn/boost/website/public_html/live/feed/history/ You see the notes so far at: http://www.boost.org/users/history/version_1_54_0.html And while I'm at it, I've also added the new libraries to: http://www.boost.org/doc/libs/1_54_0/ thank you, Daniel

11 16

[1.54.0][range] add release note
by Akira Takahashi 26 Jun '13

26 Jun '13

Hi, I think missing Boost.Range release note for 1.54.0. https://svn.boost.org/svn/boost/website/public_html/live/feed/history/boost… Please see changeset: https://svn.boost.org/trac/boost/changeset/84823 Changeset 84823 Timestamp:06/17/13 22:22:07 Author:nathanridge Message:[range] Merge Boost.Range bug fixes to release branch (fixes #6944; fixes #7407; fixes #7408; fixes #7731; fixes #7827; fixes #8338; fixes #8453). Thanks, Akira

2 1

[Boost][asio]How add a timeout to asio connection?
by Renato Forti 25 Jun '13

25 Jun '13

Hi All, I have one problem, I have this class to connect to my server app: class session { public: static void init( const std::string& host, const std::string& port, hades::archive::archive& iarch, hades::archive::archive& oarch) { boost::asio::io_service io_service; client client(io_service, host, port, iarch, oarch); io_service.run(); } }; The problem is : if my server is down, my client (session) will block on io_service.run(); the client nerves end. Then I try to add a time out: class client { public: /// Constructor starts the asynchronous connect operation. client(boost::asio::io_service& io_service, const std::string& host, const std::string& port, // service hades::archive::archive& iarch, hades::archive::archive& oarch) : connection_(io_service) , deadline_(io_service) , iarch_(&iarch) , oarch_(&oarch) { deadline_.async_wait(boost::bind(&client::check_deadline, this)); deadline_.expires_from_now(boost::posix_time::seconds(30)); // Resolve the host name into an IP address. boost::asio::ip::tcp::resolver resolver(io_service); boost::asio::ip::tcp::resolver::query query(host, port); boost::asio::ip::tcp::resolver::iterator endpoint_iterator = resolver.resolve(query); // Start an asynchronous connect operation. boost::asio::async_connect(connection_.socket(), endpoint_iterator, boost::bind(&client::handle_connect, this, boost::asio::placeholders::error)); } /// Handle completion of a connect operation. void handle_connect(const boost::system::error_code& e) { if (!e) { // Successfully established connection. Start operation to read the list // of stocks. The connection::async_read() function will automatically // decode the data that is read from the underlying socket. connection_.async_read(*oarch_, boost::bind(&client::handle_read, this, boost::asio::placeholders::error)); connection_.async_write(*iarch_, boost::bind(&client::handle_write, this, boost::asio::placeholders::error)) ; } else { // An error occurred. throw sync_client_exception(e.message()); } } // Handle completion of a write operation. void handle_write(const boost::system::error_code& e) { } // Handle completion of a read operation. void handle_read(const boost::system::error_code& e) { } void check_deadline() { // Check whether the deadline has passed. We compare the deadline against // the current time since a new asynchronous operation may have moved the // deadline before this actor had a chance to run. if (deadline_.expires_at() <= deadline_timer::traits_type::now()) { // The deadline has passed. The socket is closed so that any outstanding // asynchronous operations are cancelled. connection_.socket().close(); // There is no longer an active deadline. The expiry is set to positive // infinity so that the actor takes no action until a new deadline is set. deadline_.expires_at(boost::posix_time::pos_infin); throw sync_client_exception("Time out : deadline on client!"); } // Put the actor back to sleep. deadline_.async_wait(boost::bind(&client::check_deadline, this)); } private: // The connection to the server. dsafe::sync::connection connection_; // The data received from the server. hades::archive::archive *iarch_; hades::archive::archive *oarch_; deadline_timer deadline_; }; The problem is that now the timeout expires even if the connection to the server occurs. What is wrong? My timeout should be disabled when the connection is successful! How do I get it? Only when the connection fails it should be called! Thanks for clarification

3 2

Could the custom allocator for flyweight hashed_factory be the boost::interprocess::allocator?
by Jin Chen 25 Jun '13

25 Jun '13

I want to use boost::flyweight to do the dedupilcation of boost::interprocess::basic_string object. I wrote a small test program for that. In my program: The flyweight works fine with the interprocess::basic_string which uses the interprocess::allocator only with the default hashed_factory. The default hashed_factory is ideal except that it uses std::allocator instead of interprocess::allocator. I followed the http://www.boost.org/doc/libs/1_53_0/libs/flyweight/doc/tutorial/configurat… specifier of a custom hash_factory which can change its allocator to the interprocess one, but then got insanely long compiler error that is super hard to decode... Right now, I don't know if only use interprocess::allocator in interprocess::basic_string alone will make the flyweight object be shared by multiple process, guess probably not... Then wonder whether that I didn't use the right syntax for custom hashed_factory or flyweight is compatible with boost::interprocess at all... If it is compatible, what's the right syntax for that? How shall I change my code? Below is a test program attached. The code could compile now with flyweight's default hashed_factory. The goal is to make it compile with ShmStringHashedFactory which use the interprocess allocator.

2 1

Proposal for a thread "collision" detector
by Gaetano Mendola 24 Jun '13

24 Jun '13

I would like to know if Boost community could be interested in adopting a check mechanism that is able to detect if a not supposed thread safe class is used by multiple threads in unsafe way. This tecnique has saved us a lot of headache especially when code refactoring on old code is performed. Better to explain it, without enter in the detail of the implementation, with some examples: Example: Queue implementation non thread-safe but still usable if clients are synchronized somehow. class NonThreadSafeQueue { public: ... void push(int) { DFAKE_SCOPED_LOCK(push_pop_); ... } int pop() { DFAKE_SCOPED_LOCK(push_pop_); ... } ... private: DFAKE_MUTEX(push_pop_); }; Example: Queue implementation not usable even if clients are synchronized, so only one thread in the class life cycle can use the two members push/pop. In this case the macro DFAKE_SCOPED_LOCK_THREAD_LOCKED pins the specified critical section the first time a thread enters push or pop, from that time on only that thread is allowed to execute push or pop. class NonThreadSafeQueue { public: ... void push(int) { DFAKE_SCOPED_LOCK_THREAD_LOCKED(push_pop_); ... } int pop() { DFAKE_SCOPED_LOCK_THREAD_LOCKED(push_pop_); ... } ... private: DFAKE_MUTEX(push_pop_); }; Example: Class that has to be contructed/destroyed on same thread, it has a "shareable" method (with external syncronization) and a not shareable method (even with external synchronization). In this case 3 Critical sections have to be defined class ExoticClass { public: ExoticClass() { DFAKE_SCOPED_LOCK_THREAD_LOCKED(ctor_dtor_); ... } ~ExoticClass() { DFAKE_SCOPED_LOCK_THREAD_LOCKED(ctor_dtor_); ... } void Shareable() { DFAKE_SCOPED_LOCK(shareable_section_); ... } void NotShareable() { DFAKE_SCOPED_LOCK_THREAD_LOCKED(ctor_dtor_); ... } ... private: DFAKE_MUTEX(ctor_dtor_) DFAKE_MUTEX(shareable_section_) }; DFAKE_SCOPED_LOCK will "throw an exception" or will call an "abort" in case of check failed. This tecnique doesn't involve real lock/unlock but uses atomic operations, also the various macros DFAKE_XXXXXXXXX are defined void when NDEBUG is defined. Any comment is appreciated. Regards Gaetano Mendola

3 3

The release branch is CLOSED - except by specific permission
by Marshall Clow 24 Jun '13

24 Jun '13

We're counting down to release next Monday. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

Heads up - Release branch closed as of tomorrow
by Marshall Clow 24 Jun '13

24 Jun '13

Starting tomorrow (Monday, June 27), the release branch will be closed, except by permission from the release managers. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 5

[smart_ptr] enable_shared_from_this and shared_ptr to a base class
by Adam Romanek 24 Jun '13

24 Jun '13

Hi, I have a question related to using shared_from_this() and a shared_ptr to a base class. Here's a modified version of the enable_shared_from_this usage example from its documentation web page: #include <boost/enable_shared_from_this.hpp> #include <boost/shared_ptr.hpp> #include <cassert> class X { public: virtual void foo() = 0; }; class Y: public X, public boost::enable_shared_from_this<Y> { virtual void foo() { shared_from_this(); } }; int main() { X* x_ptr = new Y; boost::shared_ptr<X> sp(x_ptr); sp->foo(); } First, class Y is now derived from class X. Secondly, shared_ptr's template argument is now X and the parameter to the shared_ptr's constructor is now a pointer to X. Now, calling shared_from_this() in X and/or Y throws boost::bad_weak_ptr. Is this correct behavior? Is it documented somewhere? I know that the example is a bit unrealistic since most of the time shared_ptr is constructed directly from the pointer returned by 'new Y' or created by make_shared() but still, this is something that bothers me. WBR, Adam Romanek

3 9

Boost.Spirit how to use token in functor
by ... ... 24 Jun '13

24 Jun '13

Hi, I have a functor which is working, but its argument, which I don't know its type, I don't know what to do with it. I want to extract data out of it, I want to know is beginning and its end, I want to display the the content of the string character in my consol... but I can't retrieve this information. How could I archieve it ? What is the type of the argument relay to my function ? Is there a dOxygen like documentation (the one on the Boost site is great but a formal documentaton is also interesting). Where is the description and code source of this type ? Here is the code of my functor : struct counter{ counter() : j(0) {j = new int();} counter(const counter &model) : j(model.j) {} template <typename Token> bool operator()(Token const& t){// t is the argument I want to use ++i; ++(*j); std::ostringstream oss; oss << "global : " << i << " membre : " << *j;//typeid(t).name(); printf("%s\n", oss.str().c_str()); return true; } int* j;}; Thanks every one, cordialy,Guillaume Bersac237bis rue de Pessac33000 Bordeaux06.65.30.89.43

2 1

De Bruijn Bind (alternate bind syntax) Interest?
by David Sankel 24 Jun '13

24 Jun '13

Hello all, I've been working on an alternate bind syntax based on De Bruijn indices[1]. The syntax is very simple, yet the terms are very powerful. Here is an example of a function const that takes in an argument c and returns another function that, for all input, returns c: //λx.λy.x = λλ1 with De Bruijn indices. auto const_ = abs<1>( abs<1>( var<1,0>() ) ); More examples, further explanation, and an implementation are available here[2]. I'm thinking that this library could also be useful as a core for more syntax heavy bind variations. David [1] http://en.wikipedia.org/wiki/De_Bruijn_index [2] http://bitbucket.org/camior/de-bruijn-bind/ -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

11 73

Error while linking boost. spirit
by ... ... 23 Jun '13

23 Jun '13

Hi, I just downloaded, compiled and install boost.It seems like the installation process worked fine and I successfully compiled a program using boost (boost.log for instance). But when I try to compile an example writed by the developpers of boost.spirit, it fail ! It doesn't seem like it's an inclusion resolution problems, I don't know what to do. Please help me. Here is my code (I paste it from this page) : #include <stdio.h>#include <stdlib.h> #include <boost/spirit/include/lex_lexertl.hpp>#include <boost/spirit/include/phoenix_operator.hpp>#include <boost/spirit/include/phoenix_statement.hpp>#include <boost/spirit/include/phoenix_algorithm.hpp>#include <boost/spirit/include/phoenix_core.hpp>#define BOOST_ALL_DYN_LINK//without it boost.log glitch#include <boost/log/trivial.hpp> int main(){ BOOST_LOG_TRIVIAL(trace) << "boost.log is working !"; typedef lex::lexertl::token<char const*, lex::omit, boost::mpl::false_> token_type; typedef lex::lexertl::actor_lexer<token_type> lexer_type; word_count_tokens<lexer_type> word_count_lexer; std::string str (read_from_file("mainwindow.cpp.txt")); char const* first = str.c_str(); char const* last = &first[str.size()]; lexer_type::iterator_type iter = word_count_lexer.begin(first, last); lexer_type::iterator_type end = word_count_lexer.end(); while (iter != end && token_is_valid(*iter)) ++iter; if (iter == end) { std::cout << "lines: " << word_count_lexer.l << ", words: " << word_count_lexer.w << ", characters: " << word_count_lexer.c << "\n"; } else { std::string rest(first, last); std::cout << "Lexical analysis failed\n" << "stopped at: \"" << rest << "\"\n"; } return 0; }} And here is my error log : 11:32:39 **** Incremental Build of configuration Default for project synthax_analyser ****make all g++ -O2 -g -Wall -fmessage-length=0 -c -o synthax_analyser.o synthax_analyser.cppsynthax_analyser.cpp: In function ‘int main()’:synthax_analyser.cpp:24:4: error: ‘lex’ does not name a typesynthax_analyser.cpp:27:10: error: ‘lex’ does not name a typesynthax_analyser.cpp:29:2: error: ‘word_count_tokens’ was not declared in this scopesynthax_analyser.cpp:29:20: error: ‘lexer_type’ was not declared in this scopesynthax_analyser.cpp:29:20: note: suggested alternative:In file included from /usr/local/include/boost/spirit/home/lex/meta_compiler.hpp:16:0, from /usr/local/include/boost/spirit/home/lex/reference.hpp:14, from /usr/local/include/boost/spirit/home/lex/lexer/token_def.hpp:21, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:14, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/spirit/home/lex/lexer_type.hpp:20:12: note: ‘boost::spirit::lex::lexer_type’synthax_analyser.cpp:29:32: error: ‘word_count_lexer’ was not declared in this scopesynthax_analyser.cpp:31:54: error: ‘read_from_file’ was not declared in this scopesynthax_analyser.cpp:35:2: error: ‘lexer_type’ is not a class or namespacesynthax_analyser.cpp:35:28: error: expected ‘;’ before ‘iter’synthax_analyser.cpp:36:3: error: ‘lexer_type’ is not a class or namespacesynthax_analyser.cpp:36:29: error: expected ‘;’ before ‘end’synthax_analyser.cpp:38:9: error: ‘iter’ was not declared in this scopesynthax_analyser.cpp:38:17: error: ‘end’ was not declared in this scopesynthax_analyser.cpp:38:17: note: suggested alternatives:In file included from /usr/local/include/boost/range/empty.hpp:20:0, from /usr/local/include/boost/proto/functional/range/empty.hpp:12, from /usr/local/include/boost/proto/functional/range.hpp:13, from /usr/local/include/boost/proto/functional.hpp:14, from /usr/local/include/boost/proto/proto.hpp:16, from /usr/local/include/boost/spirit/home/support/terminal.hpp:18, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/range/end.hpp:106:61: note: ‘boost::range_adl_barrier::end’In file included from /usr/local/include/boost/fusion/container/list/cons.hpp:14:0, from /usr/local/include/boost/fusion/iterator/segmented_iterator.hpp:13, from /usr/local/include/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:11, from /usr/local/include/boost/fusion/sequence/intrinsic/begin.hpp:17, from /usr/local/include/boost/fusion/container/vector/vector10.hpp:15, from /usr/local/include/boost/fusion/container/vector.hpp:12, from /usr/local/include/boost/fusion/include/vector.hpp:10, from /usr/local/include/boost/spirit/home/phoenix/core/limits.hpp:73, from /usr/local/include/boost/spirit/home/phoenix/core.hpp:11, from /usr/local/include/boost/spirit/include/phoenix_core.hpp:14, from /usr/local/include/boost/spirit/home/support/terminal.hpp:16, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/fusion/sequence/intrinsic/end.hpp:89:5: note: ‘boost::fusion::end’In file included from /usr/local/include/boost/fusion/sequence/intrinsic/begin.hpp:13:0, from /usr/local/include/boost/fusion/container/vector/vector10.hpp:15, from /usr/local/include/boost/fusion/container/vector.hpp:12, from /usr/local/include/boost/fusion/include/vector.hpp:10, from /usr/local/include/boost/spirit/home/phoenix/core/limits.hpp:73, from /usr/local/include/boost/spirit/home/phoenix/core.hpp:11, from /usr/local/include/boost/spirit/include/phoenix_core.hpp:14, from /usr/local/include/boost/spirit/home/support/terminal.hpp:16, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/fusion/sequence/intrinsic_fwd.hpp:67:16: note: ‘boost::fusion::result_of::end’In file included from /usr/local/include/boost/fusion/support/sequence_base.hpp:11:0, from /usr/local/include/boost/fusion/container/vector/vector10.hpp:11, from /usr/local/include/boost/fusion/container/vector.hpp:12, from /usr/local/include/boost/fusion/include/vector.hpp:10, from /usr/local/include/boost/spirit/home/phoenix/core/limits.hpp:73, from /usr/local/include/boost/spirit/home/phoenix/core.hpp:11, from /usr/local/include/boost/spirit/include/phoenix_core.hpp:14, from /usr/local/include/boost/spirit/home/support/terminal.hpp:16, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/mpl/begin_end_fwd.hpp:23:38: note: ‘boost::mpl::end’In file included from /usr/local/include/boost/proto/functional/range.hpp:14:0, from /usr/local/include/boost/proto/functional.hpp:14, from /usr/local/include/boost/proto/proto.hpp:16, from /usr/local/include/boost/spirit/home/support/terminal.hpp:18, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/proto/functional/range/end.hpp:19:12: note: ‘boost::proto::functional::end’In file included from /usr/local/include/boost/range/empty.hpp:20:0, from /usr/local/include/boost/proto/functional/range/empty.hpp:12, from /usr/local/include/boost/proto/functional/range.hpp:13, from /usr/local/include/boost/proto/functional.hpp:14, from /usr/local/include/boost/proto/proto.hpp:16, from /usr/local/include/boost/spirit/home/support/terminal.hpp:18, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/range/end.hpp:106:61: note: ‘boost::range_adl_barrier::end’In file included from /usr/local/include/boost/spirit/home/support/string_traits.hpp:16:0, from /usr/local/include/boost/spirit/home/support/nonterminal/expand_arg.hpp:20, from /usr/local/include/boost/spirit/home/support/context.hpp:18, from /usr/local/include/boost/spirit/home/qi/domain.hpp:18, from /usr/local/include/boost/spirit/home/qi/parser.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/token_def.hpp:17, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:14, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/spirit/home/support/container.hpp:445:5: note: ‘boost::spirit::traits::end’In file included from /usr/local/include/boost/spirit/home/support/handles_container.hpp:14:0, from /usr/local/include/boost/spirit/home/lex/lexer/token_def.hpp:16, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:14, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/spirit/home/support/attributes_fwd.hpp:43:12: note: ‘boost::spirit::result_of::end’In file included from /usr/local/include/boost/spirit/home/support/info.hpp:17:0, from /usr/local/include/boost/spirit/home/lex/lexer/token_def.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:14, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/foreach.hpp:730:1: note: ‘boost::foreach_detail_::end’synthax_analyser.cpp:38:44: error: ‘token_is_valid’ was not declared in this scopesynthax_analyser.cpp:38:44: note: suggested alternatives:In file included from /usr/local/include/boost/spirit/home/lex/lexer/lexertl/lexer.hpp:20:0, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:16, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/spirit/home/lex/lexer/lexertl/token.hpp:415:5: note: ‘boost::spirit::lex::lexertl::token_is_valid’In file included from /usr/local/include/boost/spirit/home/lex/lexer/lexertl/iterator.hpp:18:0, from /usr/local/include/boost/spirit/home/lex/lexer/lexertl/lexer.hpp:23, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:16, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/spirit/home/support/iterators/detail/split_functor_input_policy.hpp:19:21: note: ‘boost::spirit::iterator_policies::split_functor_input_is_valid_test_::token_is_valid’synthax_analyser.cpp:41:7: error: ‘iter’ was not declared in this scopesynthax_analyser.cpp:41:15: error: ‘end’ was not declared in this scopesynthax_analyser.cpp:41:15: note: suggested alternatives:In file included from /usr/local/include/boost/range/empty.hpp:20:0, from /usr/local/include/boost/proto/functional/range/empty.hpp:12, from /usr/local/include/boost/proto/functional/range.hpp:13, from /usr/local/include/boost/proto/functional.hpp:14, from /usr/local/include/boost/proto/proto.hpp:16, from /usr/local/include/boost/spirit/home/support/terminal.hpp:18, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/range/end.hpp:106:61: note: ‘boost::range_adl_barrier::end’In file included from /usr/local/include/boost/fusion/container/list/cons.hpp:14:0, from /usr/local/include/boost/fusion/iterator/segmented_iterator.hpp:13, from /usr/local/include/boost/fusion/sequence/intrinsic/detail/segmented_begin.hpp:11, from /usr/local/include/boost/fusion/sequence/intrinsic/begin.hpp:17, from /usr/local/include/boost/fusion/container/vector/vector10.hpp:15, from /usr/local/include/boost/fusion/container/vector.hpp:12, from /usr/local/include/boost/fusion/include/vector.hpp:10, from /usr/local/include/boost/spirit/home/phoenix/core/limits.hpp:73, from /usr/local/include/boost/spirit/home/phoenix/core.hpp:11, from /usr/local/include/boost/spirit/include/phoenix_core.hpp:14, from /usr/local/include/boost/spirit/home/support/terminal.hpp:16, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/fusion/sequence/intrinsic/end.hpp:89:5: note: ‘boost::fusion::end’In file included from /usr/local/include/boost/fusion/sequence/intrinsic/begin.hpp:13:0, from /usr/local/include/boost/fusion/container/vector/vector10.hpp:15, from /usr/local/include/boost/fusion/container/vector.hpp:12, from /usr/local/include/boost/fusion/include/vector.hpp:10, from /usr/local/include/boost/spirit/home/phoenix/core/limits.hpp:73, from /usr/local/include/boost/spirit/home/phoenix/core.hpp:11, from /usr/local/include/boost/spirit/include/phoenix_core.hpp:14, from /usr/local/include/boost/spirit/home/support/terminal.hpp:16, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/fusion/sequence/intrinsic_fwd.hpp:67:16: note: ‘boost::fusion::result_of::end’In file included from /usr/local/include/boost/fusion/support/sequence_base.hpp:11:0, from /usr/local/include/boost/fusion/container/vector/vector10.hpp:11, from /usr/local/include/boost/fusion/container/vector.hpp:12, from /usr/local/include/boost/fusion/include/vector.hpp:10, from /usr/local/include/boost/spirit/home/phoenix/core/limits.hpp:73, from /usr/local/include/boost/spirit/home/phoenix/core.hpp:11, from /usr/local/include/boost/spirit/include/phoenix_core.hpp:14, from /usr/local/include/boost/spirit/home/support/terminal.hpp:16, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/mpl/begin_end_fwd.hpp:23:38: note: ‘boost::mpl::end’In file included from /usr/local/include/boost/proto/functional/range.hpp:14:0, from /usr/local/include/boost/proto/functional.hpp:14, from /usr/local/include/boost/proto/proto.hpp:16, from /usr/local/include/boost/spirit/home/support/terminal.hpp:18, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/proto/functional/range/end.hpp:19:12: note: ‘boost::proto::functional::end’In file included from /usr/local/include/boost/range/empty.hpp:20:0, from /usr/local/include/boost/proto/functional/range/empty.hpp:12, from /usr/local/include/boost/proto/functional/range.hpp:13, from /usr/local/include/boost/proto/functional.hpp:14, from /usr/local/include/boost/proto/proto.hpp:16, from /usr/local/include/boost/spirit/home/support/terminal.hpp:18, from /usr/local/include/boost/spirit/home/support/common_terminals.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/terminals.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:13, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/range/end.hpp:106:61: note: ‘boost::range_adl_barrier::end’In file included from /usr/local/include/boost/spirit/home/support/string_traits.hpp:16:0, from /usr/local/include/boost/spirit/home/support/nonterminal/expand_arg.hpp:20, from /usr/local/include/boost/spirit/home/support/context.hpp:18, from /usr/local/include/boost/spirit/home/qi/domain.hpp:18, from /usr/local/include/boost/spirit/home/qi/parser.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer/token_def.hpp:17, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:14, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/spirit/home/support/container.hpp:445:5: note: ‘boost::spirit::traits::end’In file included from /usr/local/include/boost/spirit/home/support/handles_container.hpp:14:0, from /usr/local/include/boost/spirit/home/lex/lexer/token_def.hpp:16, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:14, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/spirit/home/support/attributes_fwd.hpp:43:12: note: ‘boost::spirit::result_of::end’In file included from /usr/local/include/boost/spirit/home/support/info.hpp:17:0, from /usr/local/include/boost/spirit/home/lex/lexer/token_def.hpp:15, from /usr/local/include/boost/spirit/home/lex/lexer.hpp:14, from /usr/local/include/boost/spirit/home/lex.hpp:13, from /usr/local/include/boost/spirit/home/lex/lexer_lexertl.hpp:15, from /usr/local/include/boost/spirit/include/lex_lexertl.hpp:16, from synthax_analyser.cpp:12:/usr/local/include/boost/foreach.hpp:730:1: note: ‘boost::foreach_detail_::end’synthax_analyser.cpp: At global scope:synthax_analyser.cpp:54:1: error: expected declaration before ‘}’ tokenmake: *** [synthax_analyser.o] Error 1 Cordialy,Guillaume Bersac237bis rue de Pessac33000 Bordeaux06.65.30.89.43

5 5

concurrent garbage collector
by Taylor Holliday 23 Jun '13

23 Jun '13

Hey Boost, After struggling with breaking shared_ptr cycles in my app, I wrote a little concurrent garbage collector which uses boost::lockfree::queue. Its actually fairly general purpose, and I've released the code here: https://gist.github.com/wtholliday/5793270 Inspired by my question on stack overflow: http://stackoverflow.com/questions/17116189/concurrent-garbage-collection-f… I'm also working on releasing my unit test... its just quite dependent on other code. For the interface: the basic idea is you have a RootPtr<T> used to manage the collector's root set (please forgive my propensity for CamelCase). You have to explicitly manage references between collectable objects (via AddEdge and RemoveEdge functions), but I think that could be made safe using another smart pointer type which knows the collectable object which owns it. At this point I'm not too concerned about performance, as my object graphs aren't that big. I bet a GC guru could implement this without using a queue of events. Anyway, this is the kind of thing I'd love to see in boost someday, so it would be great to read your opinions of it :-) cheers - Taylor W. Taylor Holliday, Owner/Founder Subatomic Software, San Francisco

3 4