- Boost - lists.preview.boost.org

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

Re: [boost] [system] Static initialization of boost shared objects question
by Chris Stylianou 02 Jul '13

02 Jul '13

Has anyone looked into this issue, I am also experiencing the deadlock issue described above when using the boost libraries build in debug mode (GCC 1.48.0, 64bit) -- View this message in context: http://boost.2283326.n4.nabble.com/Static-initialization-of-boost-shared-ob… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

zlib not building (fedora x86_64)
by Neal Becker 02 Jul '13

02 Jul '13

I noticed zlib are not being built. I don't know why. rpm -qa zlib* zlib-1.2.7-9.fc18.i686 zlib-1.2.7-9.fc18.x86_64 zlib-devel-1.2.7-9.fc18.x86_64 bjam cxxflags=-march=native -sHAVE_ICU=1 -sEXPAT_INCLUDE=/usr - sEXPAT_LIBPATH=/usr/lib64 --layout=tagged threading=single,multi link=shared stage warning: No toolsets are configured. warning: Configuring default toolset "gcc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html Performing configuration checks - 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes error: No best alternative for libs/coroutine/build/allocator_sources next alternative: required properties: <link>static <target-os>windows <threading>multi not matched next alternative: required properties: <link>static <segmented-stacks>on <threading>multi not matched next alternative: required properties: <link>static <threading>multi not matched - has_icu builds : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no - iconv (libc) : yes - icu : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. error: No best alternative for libs/coroutine/build/allocator_sources next alternative: required properties: <link>static <target-os>windows <threading>multi not matched next alternative: required properties: <link>static <segmented-stacks>on <threading>multi not matched next alternative: required properties: <link>static <threading>multi not matched - zlib : no (cached) Component configuration: - atomic : building - chrono : building - context : building - coroutine : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building

1 0

boost 1.54.0 support for VS2013
by Charles_J_Wilson＠Dell.com 01 Jul '13

01 Jul '13

Has visualc.hpp been updated to support VC++12? (this was released in Visual Studio 2013 preview). I get the following issue with 1.54.0 beta built with VC++11 when compiling using VC++12: Error 1 error C2039: 'assert_not_arg' : is not a member of 'boost::mpl' (..\..\..\Logging\source\Core.cpp) C:\Users\Charles_J_Wilson\Documents\Projects\external\open_source\boost\1.54.0\boost_1_54_0\boost\iterator\detail\facade_iterator_category.hpp 166 Which is: # if !BOOST_WORKAROUND(BOOST_MSVC, <= 1300) BOOST_MPL_ASSERT_NOT((is_iterator_category<Traversal>)); # endif The beta doesn't recognize the compiler version and suggests running the config tests. Where are the instructions for that? Charles Wilson Principal Software Development Engineer Dell | Enterprise Solutions Group

2 1

[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

Re: [boost] [thread] synchronized_value: value and move semantics
by Ben Pope 27 Jun '13

27 Jun '13

On 21/02/13 02:02, Vicente J. Botet Escriba wrote: > > Hi, > > boost::synchronized_value (not released yet [1][2][3]) is based on [4]. > See below part of this paper adapted to the Boost.Thread interface. > > Currently boost::synchronized_value is in addition Copyable and > Swappable. I was wondering if it is worth adding value and move > semantics to synchronized_value. Making it EqualityComparable, > LessThanComparable and Movable if the underlying type satisfy these > requirements will allow to store them on a Boost.Container/C++11 container. > > Do you see something completely wrong with this addition? > Has some of you had a need for this? Could you share the context? Sorry, I'm a bit late to the party and not really answering the question. I can see the usefulness of synchronized_value for C++03, but not in C++11. It's just too easy to forget to call the synchronise() member: boost::synchronized_value<std::queue<int>> synch_queue; if(!synch_queue->empty()) synch_queue->pop(); when was was meant was (excuse use of auto, I've become lazy): boost::synchronized_value<std::queue<int>> synch_queue; { auto lock = synch_queue.synchronize(); if(!synch_queue->empty()) synch_queue->pop(); } This is neither safe or efficient (2 lock/unlocks). I think this should just not exist in C++11 and instead be replaced by something like monitor<T> described by Herb Sutter [1]: monitor<std::queue<int>> synch_queue; queue([](std::queue& q) { if(!q.empty()) q.pop(); } Now we're safe and efficient (one lock/unlock per block). Since movability is a C++11 thing, can we have something harder to use incorrectly than synchronized_value for C++11? I guess my point is rather than C++11ifying synchronized_value, can we have monitor instead? Thoughts? Ben [1] http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Herb-Sutter-Con… From 0:40:00

4 4

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

Re: [boost] De Bruijn Bind (alternate bind syntax) Interest?
by Larry Evans 24 Jun '13

24 Jun '13

On 09/02/10 16:08, David Sankel wrote:> 2010/9/2 David Sankel <camior(a)gmail.com> > >> 2010/9/2 Dave Abrahams <dave(a)boostpro.com> >> >> On Thu, Sep 2, 2010 at 11:57 AM, David Sankel <camior(a)gmail.com> wrote: >>> >>>> 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. >>>> >>> >>> Not according to the page you linked below. What am I missing? >>> >>> [1] http://en.wikipedia.org/wiki/De_Bruijn_index >>> >> >> Sorry about that. The wikipedia page uses 1-indexed indices where I'm using >> 0-indexed indices. So, increment 1 on all my examples to get the wikipedia >> syntax. >> > > I'm beginning to think it is better to use 1-indexing instead of 0-indexing > all around. It will be both compatible with the Wikipedia page and familiar > to boost bind/lambda users. > > Funny thing is, I started with 1-indexing but changed it to 0-indexing for > the fallacious reasoning of the arrrrgh function that Dave A mentioned. > Hi David, I looked at the web page mentioned in your first post to this thread and could not understand the flip example: For flip, I'm introducing subscripts on abstractions (λ) to indicate the number of arguments. For the variables (1,2,etc.) I use a subscript to indicate which argument of the abstraction it refers to. flip = λx.λ(y,z).x(z,y) = λ₁λ₂1(1₁, 2₀) which seems to have a 0 for the subscript of 2. and 1 for the subscript of 1. That's consistent with the argument indices starting at 0 (1₁ corresponds z {the 2nd argument in the argument list, (z,y)}, and 2₀ corresponds to y {the 1st argument in the argument list, (z,y)}); however, subscrited numbers should be the same since both y and z are bound by the same lamba, the nearest one corresponding to number 1. Hence, shouldn't the above be: flip = λx.λ(y,z).x(z,y) = λ₁λ₂2₀(1₁, 1₀) ? Also, since the abstraction indices seem to start at 1, shouldn't the argument indices also start at 1? I think that would make the notation more consistent, and would result in: flip = λx.λ(y,z).x(z,y) = λ₁λ₂2_1(1_2, 1_1) (where a subscript of I have been replaced with _I).

2 1

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