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

Re: [Boost-users] logical_and, boost::bind, and boost::function
by Simmons, Aaron 10 Aug '05

10 Aug '05

>Alan's post made me realize what's happening. Indeed, this last bind() >doesn't know that funcFoo and funcBar are functions that it should >call. You can tell it to consider them as functions by calling bind() >on them: Rather than wrapping another bind around them, is it possible to do some kind of clever casting, so that bind wouldn't see them as booleans? Btw, is the way I'm using function and bind not an intended use case? It seems natural enough, but by its behavior perhaps no one thought about it before... Thanks, aaron

2 1

A error occurs when compiling the wave
by 沈慧峰 10 Aug '05

10 Aug '05

Hi, respected boost maintainers. I compile the boost_1_33_0_rc2 with vc7.1 with stlport 4.62, my cl version is 13.10.3077. I compile the stlport with /Zc:wchar_t, so I change <native-wchar_t>on when compiling. Here is my script to compile boost 1.33 ------------------------------------------------------- call "c:\Program Files\Microsoft Visual Studio .NET 2003\vc7\bin\vcvars32.bat" set BOOST_ROOT=c:\temp\boost set PYTHON_ROOT=c:\python set PYTHON_VERSION=2.4 set STLPORT_PATH=c:\temp set STLPORT_4.62_PATH=C:\temp\STLport-4.6.2 set STLPORT_VERSION=4.6.2 set TOOLS=vc-7_1-stlport bjam "-sBUILD=<native-wchar_t>on" install ------------------------------------------------------- A error occur when compile instantiate_cpp_grammar.cpp. The whole error message is : "cl" /Zm800 -nologo /EHsc -c -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd /Op /wd4675 /Zc:forScope Zc:wchar_t -I"bin\boost\libs\wave\build" -I"C:\temp\boost_1_33_0" -I"c:\temp\STLport-4.6.2\stlport" -I"C:\temp\boost_1_33_0" -Fo"bin\boost\libs\wave\build\libboost_wave.lib\vc-7_1-stlport\debug\native-wchar_t-on\threading-multi\instantiate_cpp_grammar.obj" -Tp"C:\temp\boost_1_33_0\libs\wave\build\../src/instantiate_cpp_grammar.cpp" ...failed vc-C++ bin\boost\libs\wave\build\libboost_wave.lib\vc-7_1-stlport\debug\native-wchar_t-on\threading-multi\instantiate_cpp_grammar.obj... ...skipped <@boost!libs!wave!build\libboost_wave.lib\vc-7_1-stlport\debug\native-wchar_t-on\threading-multi>libboost_wave-vc71-mt-gdp-1_33.CMD for lack of <@boost!libs!wave!build\libboost_wave.lib\vc-7_1-stlport\debug\native-wchar_t-on\threading-multi>instantiate_cpp_grammar.obj... ...skipped <@boost!libs!wave!build\libboost_wave.lib\vc-7_1-stlport\debug\native-wchar_t-on\threading-multi>libboost_wave-vc71-mt-gdp-1_33.lib for lack of <@boost!libs!wave!build\libboost_wave.lib\vc-7_1-stlport\debug\native-wchar_t-on\threading-multi>instantiate_cpp_grammar.obj... ...skipped <@boost!lib>libboost_wave-vc71-mt-gdp-1_33.lib for lack of <@boost!libs!wave!build\libboost_wave.lib\vc-7_1-stlport\debug\native-wchar_t-on\threading-multi>libboost_wave-vc71-mt-gdp-1_33.lib... I do not know whether the attachment can be paste, the attachment is the scapture of the error. I also try bjam "-sBUILD=debug release <runtime-link>static/dynamic <threading>single/multi <native-wchar_t>on" install The same error occurs three times. Best regards Huifeng Shen

3 2

[Thread] How to wait for a thread until it's blocked
by Christian Henning 10 Aug '05

10 Aug '05

Hi there, seems the attention span for my last question is over. ;-) I also think that my subject was misleading. My question isn't about terminating, completing, or canceling a thread. It's about putting a thread in a blocked state. Please consider the following code. All functions, except for the run(), are called by the GUI thread. The _oThread object is RAII-object ( Resource Allocation is Initialization ). // Only called by GUI thread fvAsynchronousSequencer::fvAsynchronousSequencer() : _oThread ( ) , _bTerminateSequencerThread ( false ) , _bStop( false ) { _oThread.create( this, _run ); } // Only called by GUI thread fvAsynchronousSequencer::~fvAsynchronousSequencer() throw() { _bTerminateSequencerThread = true; // wake up the thread, if necessary _oRunCondition.notify_one(); // wait until the thread is terminated { boost::mutex::scoped_lock oLock( _oTerminateMutex ); _oTerminateCond.wait( oLock ); } } // Only called by GUI thread void fvAsynchronousSequencer::start() { _bStop = false; _oRunCondition.notify_one(); } // Only called by GUI thread void fvAsynchronousSequencer::stop() throw() { _bStop = true; // I would like to wait until the _oThread is a in blocked position. } void fvAsynchronousSequencer::_run() throw() { boost::mutex::scoped_lock oLock( _oRunMutex ); // Wait until someone calls start() _oRunCondition.wait( oLock ); do { // do something useful while( _bStop ) _oRunCondition.wait( oLock ); } while( !_bTerminateSequencerThread ); // now finish destructing the sequencer _oTerminateCond.notify_one(); } So, I will ask again my question. Is there a way that the stop() will only return when the worker thread in in blocked state? Right now, I just set _bStop to true and stop() returns. This approach is of course rife for deadlocks. Thanks again, Christian

1 0

logical_and, boost::bind, and boost::function
by Simmons, Aaron 10 Aug '05

10 Aug '05

I'm trying to use boost::bind and boost::function with std::logical_not and I've run into some strange template magic that I don't understand. In the example below, I use boost::function to help compose several boost::bind calls so that I don't have to do it all on one line (I find that this improves readability). The problem is that when I do this, the functions that are bound with boost::bind never get called. They will get called only if I construct everything on one line. (???) Is this expected behavior? If so, why does it work like this? Thanks, aaron #include <algorithm> #include <functional> #include "boost/bind.hpp" #include "boost/function.hpp" using namespace std; using namespace boost; class test { public: void bindtest() { // test1: composed gradually for clarity // function<bool ()> funcFoo = bind(&test::foo, this); function<bool ()> funcBar = bind(&test::bar, this); function<bool ()> funcTest1= bind(logical_and<bool>(), funcFoo, funcBar); // doesn't call test::foo or test::bar! (returns true) bool test1= funcTest1(); cout << "test1= " << test1 << endl; // test2: composed directly on one line function<bool ()> funcTest2= bind(logical_and<bool>(), bind(&test::foo, this), bind(&test::bar, this) ); // calls test::foo and test::bar (returns false) bool test2= funcTest2(); cout << "test2= " << test2 << endl; } bool foo() { cout << "foo" << endl; return false; } bool bar() { cout << "bar" << endl; return false; } };

2 1

Re: [Boost-users] logical_and, boost::bind, and boost::function
by Alan M. Carroll 10 Aug '05

10 Aug '05

1 0

Re: [Boost-users] [Serialization] 1.33 RC1 nvp.hpp gotcha
by Richard Jennings 10 Aug '05

10 Aug '05

I am a bit baffled why you can get the example to compile! I can't try it on VC7.1 today, though I will tomorrow, however I can't see anything compiler specific about it: Serialization/nvp.hpp includes serialization/traits.hpp that defines BOOST_SERIALIZATION_TRAITS_HPP. Serialization/vector.hpp includes collections_save_imp.hpp that includes archive/basic_archive.hpp that checks for BOOST_SERIALIZATION_TRAITS_HPP being defined and thereby says #error. Therefore it appears that whenever vector.hpp is included after nvp.hpp that basic_archive will choke. BTW When I said that perhaps it only worked by luck before I meant that my application worked by luck as I was not overly careful about header inclusion order or what went in the precompiled headers and what didn't. I did _not_ mean that it's lucky the serialization library works! I have found it very simple to use and very powerful. Richard -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 09 August 2005 17:11 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Serialization] 1.33 RC1 nvp.hpp gotcha Richard Jennings wrote: > I have found that the requirement that no serialization headers can be > included before any archive headers means that you have to be careful > which serialization headers you include in your class headers and > indeed in what order you include them. It is my intention that this issue be addressed with the simple rule: "all headers from the serialization directory should follow and headers from the archive directory" I believe that this rule should be very easy to follow. As a beneficial side-effect of flagging any usage of "archive" headers in include modules for classes. This would accidently link a serialization definition with implementation of a specific archive. > > In particular if you include serialization/nvp.hpp before > serialization/vector.hpp and you use that class in another module that > does not use archiving at all then that module will hit the error > directive, example below. This would surprise me. Your example looks good to me. So I built on my own machine. Both main.cpp and B.cpp compiled without problems with VC 7.1 . So we're out of sync somehow. > A solution would seem to be that serialization/nvp.hpp should only be > included in the module that includes archive headers. This wouldn't work and shouldn't be necessary. Lets beat upon your example some more until we get the same results. > I guess what I would like is some guidance on using serialization as > it's become a bit more tricky in my experience. I would hope that its not too tricky. The system is designed to be as tricky as necessary - but no trickier. > At least you can't willy-nilly include serialization headers in any order > in any headers > and expect the application to compile. True >Perhaps it only worked by luck before! LOL - well I do consider myself a lucky person !!! But A very small observation on your code: #include <vector> // note this is superflous - but harmless #include <boost/serialization/vector.hpp> // as the above is included by this module Robert Ramey _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2

Re: [Boost-users] shared_ptr conundrum
by Timothy Ritchey 10 Aug '05

10 Aug '05

To update, my problem with shared_ptrs not being released properly went away when I upgraded my Intel compiler from 8.1.019 to 8.1.025 on my machine at work. I hate to think how many days I have been working on this...:-) Cheers, tim

1 0

bug remains in posix_time io in 1.33RC2
by Serge Skorokhodov 10 Aug '05

10 Aug '05

Hi, In 1.33RC2, the string with wrong formatted date produce wrong date-time rather than error (vc-7_1): #include <iostream> #include <sstream> #include <string> #include <stdexcept> #include "boost/date_time/posix_time/posix_time.hpp" #include "boost/date_time/posix_time/posix_time_io.hpp" using namespace std; using namespace boost::posix_time; int main() { bool except_fg = false; string pts = "2002091"; istringstream iss(pts); iss.exceptions(ios::failbit); time_input_facet* tif = new time_input_facet; tif->set_iso_format(); iss.imbue(std::locale(std::locale::classic(), tif)); ptime pt; try { iss >> pt; } catch ( const exception& e ) { cout << "Exception reading 2002091: " << e.what() << endl; except_fg = true; } if ( !except_fg ) { cout << "Date-time from 2002091: " << pt << endl; except_fg = false; } pts = "20020913T17043"; iss.str(pts); try { iss >> pt; } catch ( const exception& e ) { cout << "Exception reading 20020913T17043: " << e.what() << endl; except_fg = true; } if ( !except_fg ) { cout << "Date-time from 20020913T17043: " << pt << endl; } return 0; } Output: Date-time from 2002091: 2002-Sep-11 00:00:00 Exception reading 20020913T17043: Parse failed. No match found for '' -- Serge

2 3

[Thread] How to wait for a thread until it stopped
by Christian Henning 10 Aug '05

10 Aug '05

Hi there, I'm still working on the transistion from an old thread lib to the boost thread lib. I have two threads, the GUI thread and a worker thread. The worker thread is always inside a loop that only breaks if someone set the flag. The GUI thread has from time to time to stop the worker thread. This is currently done by setting a flag ( _bStop ) and the worker thread will eventually stop like: void run() { boost::mutex::scoped_lock oLock( _oRunMutex ); do { ... if( _bStop ) _oRunCondition.wait( oLock ); } while( _bTerminate == false ); } I believe that this implemention can lead to deadlocks. But how can I implement the behavior that the GUI thread will break until the worker thread has stopped. Thanks, Christian

1 0

Question concerning boost::tuples::length (1.33 RC2)
by Daniel Krügler 10 Aug '05

10 Aug '05

(Note: The following contribution is essentially a copy of a former one, which was, due to several administrative problems on my side, probably overlooked by the majority of concerned programers) Dear Boosters, its quite a while that I could participate in this newsgroup, so maybe my request is ol' stuff and has been answered 100 times. In case of that I apologize for the following question: I observe that boost::tuple::length in version 1.32+1.33RC2 exist two template specializations for empty tuples, namely template<> struct length<tuple<> > { BOOST_STATIC_CONSTANT(int, value = 0); }; template<> struct length<null_type> { BOOST_STATIC_CONSTANT(int, value = 0); }; which lead to the unexpected effect that e.g. typedef const tuple<> ConstEmptyTuple; int k = length<ConstEmptyTuple>::value; (modulo namespace issues) does not compile. The reason is obvious, because deduction of boost::tuples::length<ConstEmptyTuple> extracts "const tuple<>", which leads to the generic template definition: template<class T> struct length { BOOST_STATIC_CONSTANT(int, value = 1 + length<typename T::tail_type>::value); }; which does not compile in this case, because const oost::tuples::tuple<> has no tail_type. Similar situations arise for const null_type arguments and corresponding volatile variants thereof. To my humble opinion tuples::length should work independent of cv qualification of the template arguments, but this route should of course be gone in accordance to similar situations of "template predicates" in boost::mp/type_traits. One further indirection and usage of boost::remove_cv<T> could simply resolve the described problem, such as: // Define length_impl + 2 specialisation for tuple<> and null_type as // currently done for length namespace details { template <typename T> struct length_impl { .. // as before; }; template <> struct length_impl<null_type> { .. // as before; }; template <> struct length_impl<tuple<null_type, ...> > { .. // as before; }; } // One single - not specialized - length template handling all cases: template <typename T> struct length { static const int value = details::length_impl< typename ::boost::remove_cv<T>::type >::value; }; What do you think? Greetings from Bremen, Daniel Krügler

1 0