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

Re: [Boost-users] 2. TRY boost::thread - problem with worker as an inner class of a queue
by Lars Kunert 27 Jan '07

27 Jan '07

Sorry, I have have shortened the code to some degree - taking the joins out. But the problem really seams to be in the constructor: > QueueError( ST max_queue_size =1000 ) > : max_queue__size__( max_queue_size ) > , thread_( Worker( this )) > {}; In all examples given in the in boost::threads global or static member functions are called - is that neccessary??? Thank, Lars

2 1

2. TRY boost::thread - problem with worker as an inner class of a queue
by Lars Kunert 27 Jan '07

27 Jan '07

Dear Moderator! Yesterday I posted a mail to boost-users. I got a reply, that my mail awaits moderation. That mail also contained a link. The link is dead since yesterday evening. Which does usually mean that the mail was posted, but it did not show up. I have enclosed the mail again below, Thanks, Lars Kunert The following attached (downsized) program implements a queue which contains a single worker process. Int's that are pushed into the queue are popped by the worker and processed... The problem is, the program ends up with an segmentation fault. Valgrind tells me that the stack is overwritten. ==4927== Conditional jump or move depends on uninitialised value(s) ==4927== at 0x8073536: strstr (in /local/home/lkunert/projects/pg-build-4.0.3/src/cdag/threads/queue_error) ==4927== by 0x80609F5: pthread_initialize (smp.h:47) ==4927== by 0x80B2DE1: (within /local/home/lkunert/projects/pg-build-4.0.3/src/cdag/threads/queue_error) ==4927== by 0x80480E8: (within /local/home/lkunert/projects/pg-build-4.0.3/src/cdag/threads/queue_error) ==4927== by 0x80641A0: __libc_csu_init (in /local/home/lkunert/projects/pg-build-4.0.3/src/cdag/threads/queue_error) ==4927== by 0x8063FC2: __libc_start_main (in /local/home/lkunert/projects/pg-build-4.0.3/src/cdag/threads/queue_error) ==4927== by 0x8048120: ??? (start.S:102) ==4927== ==4927== Syscall param write(buf) points to uninitialised byte(s) ==4927== at 0x8063044: write (in /local/home/lkunert/projects/pg-build-4.0.3/src/cdag/threads/queue_error) ==4927== by 0x804C241: boost::thread::thread(boost::function0<void, std::allocator<boost::function_base> > const&) (in /local/home/lkunert/projects/pg-build-4.0.3/src/cdag/threads/queue_error) ==4927== by 0x804AD26: QueueError::QueueError(unsigned) (QueueError.cxx:74) ==4927== by 0x8048287: main (QueueError.cxx:150) ==4927== Address 0x52BFE04C is on thread 1's stack Line 74 corresponds to the initailisation of the worker. The thread-manual writes: *explicit* thread(*const* boost::function0<*void*>& threadfunc); *Effects*: Starts a new thread of execution and constructs a thread <http://www.boost.org/doc/html/thread.html> object representing it. Copies |threadfunc| (which in turn copies the function object wrapped by |threadfunc|) to an internal location which persists for the lifetime of the new thread of execution. Calls |operator()| on the copy of the |threadfunc| function object in the new thread of execution. Which sound good to me. Were is the mistake. class QueueError { // *** Typedefs ************************************************************* private: typedef std::queue<int> Queue; typedef boost::thread Thread; public: typedef Queue::size_type ST; // *** Inner Classes ******************************************************** private: class Worker { private: QueueError* outer_p_; public: Worker( QueueError* outer_p ) : outer_p_( outer_p ) {}; public: void operator()() { outer_p_->worker_run_(); }; }; // *** Attributes ************************************************************ public: private: ST max_queue_size_; Queue queue_; Thread thread_; boost::mutex monitor_; boost::condition space_available_, job_available_; // *** Constructors / Destructors ******************************************** public: explicit QueueError( ST max_queue_size =1000 ) : max_queue_size_( max_queue_size ) , thread_( Worker( this )) {}; // *** Methods *************************************************************** public: void push( int i ) { boost::mutex::scoped_lock lock( monitor_ ); while( queue_.size() >= max_queue_size_ ) { space_available_.wait( lock ); }; queue_.push( i ); job_available_.notify_one(); }; protected: void worker_run_() { int i =0; while( true ) { i = worker_pop_(); worker_work_( i ); }; }; int worker_pop_() { boost::mutex::scoped_lock lock( monitor_ ); while( queue_.empty()) { job_available_.wait( lock ); }; int i = queue_.front(); queue_.pop(); space_available_.notify_one(); return i; }; void worker_work_( int i ) { for( int ii= 0; ii < i; ++ii ) { // do some work double divident = 10000; double sum; for( uint divisor =1; divisor < divident; ++divisor ) { sum = divident / divisor; }; }; }; }; // class QueueError int main() { QueueError q; q.push( 10 ); q.push( 9 ); q.push( 8 ); q.push( 7 ); q.push( 6 ); return 0; };

2 1

Compiling Boost 1.33.1 & getting success w/ XP!!
by Allen 27 Jan '07

27 Jan '07

Hello all, for those who'd had problems like be getting boost to run after getting it to compile in w/ their App, here's what I did: 1. Got the absolute latest version of boost that was stable - 1.33.1 2. Followed the "Getting Started" Instructions better: a. in step 2 for XP, HAD to start a cmd tool b. HAD to run vcvarsall.bat (located @ C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat on my computer) c. I'm using the toolset vc-8_0, therefore the need for step 2.b d. cd'ed to my Boost install directory - after getting the bjam executable for XP and copying it there 1st e. ran the following commands C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat <return> bjam "-sTOOLS=vc-8_0" install 3. Took over 2 hrs to get the results in a NEW BOOST directory where only the "includes" and the "libs" were located. 4. Notice that I accepted the "default" libs that it generated. The Note on using the "-sBUILD" NEVER NEVER worked for me. The build processes kept trying to use .Net 2003 VC7 to compile with & of course couldn't find it! So boost never built correctly to begin with. Bummer! 5. Then I included the header directory in my .Net App: C:\Boost\include\boost-1_33_1 6. Thin I included the following "static" libraries in my .Net App: C:\Boost\lib\libboost_wserialization-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_date_time-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_filesystem-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_iostreams-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_prg_exec_monitor-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_program_options-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_regex-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_serialization-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_signals-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_test_exec_monitor-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_thread-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_unit_test_framework-vc80-mt-gd-1_33_1.lib C:\Boost\lib\libboost_wave-vc80-mt-gd-1_33_1.lib 7. I've NO clue what "gd" means but I sure hope it means the debug version. The docs DON'T explain this nor the -s either and I hope their updated soon to include the meaning of these nomenclatures. Well that's all & it works for me, FINALLY!!!!!!!!!!!! I'm so happy. Just wish I'd had feed back from the group on this issue but all's well that ends well. See y'all later!!! -- Sincerely, Allen Gene Allen Saucier, Jr Senior Software Engineer CAS, Inc 100 Quality Circle Huntsville, AL 35806 or PO Box 11190 Huntsville, AL 35814 (256) 922-6453 (w) "...As for I and my house, we shall follow the Lord" Joshua 24:15

5 5

Re: [Boost-users] More on Newby question re (boost::shared_ptr) enable_shared_from_this
by ethann.castell＠caliton.com 26 Jan '07

26 Jan '07

I've manage to narrow down what the problem is and created a test case that simulates my real code. The problem occurs in a destructor (of B1) when it tries to get a shared pointer to shared_from_this() from its base class (base_class). I think that the execution of the destructor hierarchy has deleted the original shared_ptr to B2 meaning that the shared_from_this() returns an error (because shared_from_this() requires that the object is managed by a shared_ptr). My original destructor code was using raw pointers (ie. this) which worked fine because the base_class destructor was last to be called and was still alive at the time when ~B2() is called. This seems like it could be a limitation of boost::shared_ptr? I have placed my code in the destructor of B2 because in my program I am never sure exactly of the lifespan of B2. During execution I accumulate information in the B2 object and then write out this information at the end of its lifespan i.e in the destructor. I'm open to any ideas including any ways that I might be able to restructure my program. #include <boost/smart_ptr.hpp> #include <boost/enable_shared_from_this.hpp> #include <boost/scoped_ptr.hpp> #include <iostream> class base_class : public boost::enable_shared_from_this<base_class> { private: boost::shared_ptr<base_class> m_Linked; // link to another base_class public: base_class(){}; base_class( boost::shared_ptr<base_class> pLinked) { m_Linked = pLinked; // store link to other base class } }; class B : public base_class { public: B(boost::shared_ptr<base_class> pLinked) : base_class( pLinked){} }; class B1 : public B { public: B1(boost::shared_ptr<base_class> pLinked) : B( pLinked){} ~B1() { try{ boost::shared_ptr<base_class> ptr_This = shared_from_this(); // Exception occurs here // Write out some links here. } catch (exception &e) { std::cout << e.what(); } } }; class B2 : public B1 { public: B2(boost::shared_ptr<base_class> pLinked) : B1( pLinked){} }; class A : public base_class { public: A() : base_class(){}; int f; void Process() { boost::shared_ptr<base_class> ptr_me = shared_from_this(); // get pointer to myself //afterwards - use_count = 2, weak_count = 2 f = 3; if (f == 3){ boost::shared_ptr<B2> ptr_b2( new B2(ptr_me) ) ; // create new B2 and pass pointer to me. }else{ // crashes with bad_weak_ptr error on this line. } } }; void main() { boost::shared_ptr<A> ptr_a( new A() ); ptr_a->Process(); } // EOF

3 2

boost::mem_fn with Alexandrescu LockingProxy
by Allison Floyd 26 Jan '07

26 Jan '07

Hello, the list. After some digging through the bind and mem_fn documentation, I have been unable to figure out whether I'm attempting to do something impossible or not. I've created a thread-safe variant of shared_ptr that uses Alexandrescu's LockingProxy to ensure that access to the contained object through operator-> correctly locks and unlocks the pointee object. In all respects save one, this "shared_locking_ptr" is syntactically equivalent to boost::shared_ptr. The one thing it cannot do is dereference the pointer via operator* (I can't figure out how to return something from operator* that remains in scope (and thus locked) long enough for the operation to complete). All well and good so far. Where I'm trying to use this beast is in boost::signals via bind (and therefore mem_fn). I'd like to connect a member function of an object to the signal through my shared_locking_ptr, so that when the signal fires it automatically locks the object, invokes the member function, and then unlocks. Shared pointers to objects are valid arguments to mem_fn; my shared_locking_ptr isn't, alas, apparently because it requires the operator* mentioned above. So: 1) Has anybody else attempted to extend shared_ptr for Alexandrescu's policy-based storage types, specifically the LockingProxy, and figured out how to overload operator* in a meaningful way? or 2) Is there some way to wheedle signals, bind, and/or mem_fn so that they only access the slot through operator->, and don't try to dereference it? If this is more properly a boost developer's list question, let me know and I'll take it there. Thanks! -- Allison Floyd

3 3

Re: [Boost-users] Compiling Boost 1.33.1 & getting success w/ XP!!
by Allen 26 Jan '07

26 Jan '07

Thank you Dave! However, I really don't know how to check the "cvs" repository. I'll look into it though. I'd appreciate a better getting started document. Thank you again.... --Allen > Today's Topics: > > 1. Re: Compiling Boost 1.33.1 & getting success w/ XP!! (David Klein) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 26 Jan 2007 16:58:21 +0100 > From: David Klein <dave_chp(a)gmx.de> > Subject: Re: [Boost-users] Compiling Boost 1.33.1 & getting success w/ > XP!! > To: boost-users(a)lists.boost.org > Message-ID: <45BA251D.3010504(a)gmx.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Allen wrote: > > Hi Allen, > >> 2. Followed the "Getting Started" Instructions better: >> > There is a new and better "Getting Started" guide in cvs. > Look for more/getting_started.html. > >> 7. I've NO clue what "gd" means but I sure hope it means the debug >> version. The docs DON'T explain this nor the -s either and I hope >> their updated soon to include the meaning of these nomenclatures. >> > They do. Search in the current Getting Started guide under Results / > Runtime. > There is a table that lists everything. > > s - Static link to runtime. > g - Debug runtime. > y - Debug Python system. > d - Debug enabled code. > p - STLport runtime, instead of the vendor toolset runtime. > n - STLport runtime using the "native" IO streams instead of the STLport > IO streams. > > -- > HTH dave > > -- Sincerely, Allen Gene Allen Saucier, Jr Senior Software Engineer CAS, Inc 100 Quality Circle Huntsville, AL 35806 or PO Box 11190 Huntsville, AL 35814 (256) 922-6453 (w) "...As for I and my house, we shall follow the Lord" Joshua 24:15

2 1

When will BOOST settle how it constructs LIB and INCLUDE directories
by Allen 26 Jan '07

26 Jan '07

Hello all, just wondering when boost will finally settle in how it constructs the lib and include directories that we use to build our apps with so that I don't have to ALWAYS change the path names w/in my applications. This is really annoying. Anyone know? -- Sincerely, Allen Gene Allen Saucier, Jr Senior Software Engineer CAS, Inc 100 Quality Circle Huntsville, AL 35806 or PO Box 11190 Huntsville, AL 35814 (256) 922-6453 (w) "...As for I and my house, we shall follow the Lord" Joshua 24:15

2 1

[boost.signals] documentation suggestion + thread-safe partial implementation
by Frank Hess 26 Jan '07

26 Jan '07

Hi, I'd like to suggest a sentence be added to the boost.signals documentation describing how to connect one signal directly to another signal. It took me a while to realize I could do things like signal.connect(boost::bind(boost::ref(otherSignal), _2)); wrapping a signal object in a boost::ref() call before passing it to boost::bind(), to get around signals being noncopyable. Before this epiphany, I kept writing trivial wrapper functions to use as slots when I wanted to connect two signals :) I imagine others who are new to boost.signals and boost in general would resort to similar tactics. By the way, I hacked up a partial implementation of boost.signals which is intended to be thread-safe, since I missed boost.signals so much in my multi-threaded code. Would anyone would be interested in this? It's just a few header files, and depends on boost (although not on boost.signals). I just did the bare minimum I need for my own use: a signal template class, signalslib::connection, and signalslib::scoped_connection. I didn't implement return values because I don't use them. I didn't implement boost::trackable because I don't see how to make automatic connection management thread-safe when a signal is connected to an object's member function. You really want to insure the slot is disconnected from the signal before the object providing the slot is destroyed. Inheriting the object from boost::trackable wouldn't seem to be good enough, since the boost::trackable destructor wouldn't get called until after the object's destructor. So you pretty much have to manually disconnect the connection at the beginning of the object's destructor. -- Frank

1 0

[interval] using crlibm for transcendental functions
by Tobias Munk 26 Jan '07

26 Jan '07

I am using a custom rounding policy for transcendental functions, based on crlibm and defined in the manner of libs/numeric/interval/examples/transc.cpp In the documentation of crlibm, it is recommended to call the init function crlibm_init() before calling one of their transcendental functions. My question now is: does anybody know if calling this init function collides with any of the boost.numeric.interval internal algorithms? On i686 and amd64 crlibm_init() instructs the FPU not to use extended arithmetics: /* An init function which sets FPU flags when needed */ unsigned long long crlibm_init() { /* Set FPU flags to use double, not double extended, with rounding to nearest */ cw = (_FPU_DEFAULT & ~_FPU_EXTENDED)|_FPU_DOUBLE; _FPU_SETCW(cw); ... } Is it necessary to reset the old state after a call of a crlibm function, for correct interval arithmetics, or is one call of crlibm_init() for the whole program sufficient? Thanks, Tobias Munk --------------------------------- NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.

2 1

regex problem: removing two elements in a row?
by Lynn Allan 26 Jan '07

26 Jan '07

I want to use boost::regex 1.33.1 and vc7.1 on a WinXp-Sp2 computer to remove common words from a file. I'm encountering a problem which seems related to having two of the common words next to each other. std::string test(" in the beginning god created the heavens and the earth "); boost::regex reg; reg.assign("( and | can | did | the | in | a )"); test = boost::regex_replace(test, reg, " "); cout << test << endl; The result is: " the beginning god created heavens the earth " Am I doing something wrong or leaving out a step? Seems like the above ought to work. It catches one of the occurrences of " the " between " created " and " heavens " but not those immediately after the " in " or " and ".

2 4