- Boost-users - lists.boost.org

The example error of boost 1.33 date_time
by 沈慧峰 19 Aug '05

19 Aug '05

"add_month" are not in date-time of boost 1.33. I have compiled date_time as the lib. The example are not in boost\libs\date_time\example, I use grep and can not find it. > The example of > "boost/doc/html/date_time/examples.html#date_time.examples.month_add" can > not be compiled. > I use the vc71+stlport 4.62, the command line is cl /MD /EHsc > /DBOOST_LIB_DIAGNOSTIC. > I also can not find this example code under the directory > "boost\libs\date_time\example\gregorian\". This example program is in cvs (http://tinyurl.com/9gnxq) Did you build the library first? This example uses one of the to_string functions. These functions depend on the compiled binary libray. I could provide more help if you post your error messages. Bart <P><HR></P>_______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Bind operator== in standard algorithms
by Alexander Borghgraef 19 Aug '05

19 Aug '05

Ok, I've just discovered boost::bind, and it is a marvelous discovery :-) Now, I do seem to have a problem: the operator overloading for logical operators seems to work on its own, but not when I apply it within standard algorithms such as find_if. Still, the bind documentation states that this should be possible, and gives examples such as: std::remove_if( first, last, !bind( &X::visible, _1 ) ); std::find_if( first, last, bind( &X::name, _1 ) == "peter" ); If we look at some simple test code I wrote: int add3( int i ){ return i + 3; }; int main() { int x = 2; int y = 5; bind( add3, _1)(x) == y; // Compiles find_if( l.begin(), l.end(), bind<int>( equal_to<int>(), bind(add3, _1), y) ); // Compiles find_if( l.begin(), l.end(), bind(add3, _1) == y ); // Doesn't compile } From the last line I get the following error message: error: no match for 'operator==' in 'boost::bind [with R = int, B1 = int, A1 = boost::arg<1>](add3, (<unnamed>::_1, boost::arg<1>())) == y' I'm puzzled why the standalone bind expression containing == does compile, whereas the one inside find_if doesn't. Of course, I do have a functional equivalent I can work with in the first find_if line, but it does seem neat to be able to write more readable code, as in the examples. Anyone care to explain this to me? Ok, standard disclaimers: I use the g++ 3.4.4 compiler on Fedora, I did include all necessary boost:: and std:: namespace stuff in my code, but left it out in this post, and I have no clue whatsoever which version of boost I have installed ( Can I find it in the code somewhere? Otherwise I'll ask the sysadmin which version he installed when I see him.). -- Alex Borghgraef

4 4

Re: [Boost-users] thread safety of the mutex ctor
by Christopher Hunt 19 Aug '05

19 Aug '05

On 18/08/2005, at 8:04 AM, boost-users-request(a)lists.boost.org wrote: > On 8/17/05, Christopher Hunt <huntc(a)internode.on.net> wrote: >> On 18/08/2005, at 1:19 AM, boost-users-request(a)lists.boost.org wrote: >> >>> I envisage two threads accessing a function like this concurrently: >>> >>> template<typename T> >>> boost::shared_ptr<T> >>> my_func() >>> { >>> static boost::mutex m; >>> boost::mutex::scoped_lock l(m); >>> >>> static boost::shared_ptr<T> p(new T); >>> return p; >>> } >>> >>> and my worry is that both threads could attempt to do the static >>> initialisation of m concurrently. Is there protection against this? >>> Is it even possible to protect against this? >> >> The scope of m is actually outside of your function given that it is >> static. Thus it will be initialised outside of your function generally >> before any other threads get to start up. > > This does not sound right to me, so I whipped up a test case... on > HP-UX, given the code: Sorry, I should have looked at the problem more closely - you're right to be suspicious of course. Stroustrup is actually pretty clear on this too, "It will be initialized only the first time the thread of execution reaches its definition". Whoops - sorry for throwing you off. Using the Singleton Design Pattern, I have a static mutex in my class covering the static instance member. Given their static member nature, they get initialised during process startup. Again Stroustrup confirms this with, "A variable defined outside any function (that is, global, namespace, and *class static variables*) is initialized (constructed) before main() is invoked,...". In case it helps, here's something that I knocked together (and tested) using the boost library. The class implements the Singleton design pattern safely and is also more robust from an exception handling perspective (note: this is the first time I've used boost threads - I'm actually using another thread class library...): ***** #include <stdexcept> #include <boost/thread/mutex.hpp> // Modified Singleton class from Gamma et. al. Returns // a reference to the instance instead of a pointer // recognising the use of exceptions. Additionally, // the instance is guaranteed to be allocated in a // thread safe manner. class Singleton { public: static Singleton& Instance() throw(std::bad_alloc); protected: Singleton() throw(std::bad_alloc); private: static Singleton* mInstanceP; static boost::mutex mInstancePMutex; }; // Implementation using namespace boost; using namespace std; Singleton* Singleton::mInstanceP = 0; mutex Singleton::mInstancePMutex; Singleton& Singleton::Instance() throw(bad_alloc) { boost::mutex::scoped_lock theInstancePMutexLock(mInstancePMutex); if (mInstanceP == 0) mInstanceP = new Singleton(); return *mInstanceP; } Singleton::Singleton() throw(bad_alloc) {} int main (int argc, char * const argv[]) { try { Singleton& theSingleton = Singleton::Instance(); // Guaranteed thread safe. } catch (const bad_alloc&) {} return 0; } ***** 'hope that this is useful. Cheers, -C

1 0

[shared_ptr][1.33.0] Header includes troublesome win32 macros.
by Jason Kankiewicz 18 Aug '05

18 Aug '05

On win32 using VC7.1, the Windows macros 'CMYK' and 'RGB' are bleeding through the 'boost/shared_ptr.hpp' header file. These are my header file's includes up to and including the offending boost header: #include <algorithm> #include <functional> #include <iterator> #include <set> #include <stdexcept> #include <string> #include <utility> #include <vector> #include <boost/shared_ptr.hpp> #undef CMYK // I added this to make it compile. #undef RGB // I added this to make it compile. The declarations of my 'CMYK' and 'RGB' functions within this header compiled without error until I installed the 1.33.0 release of Boost. I had been using the CVS HEAD previously so the error must have been introduced during the week or two prior to release.

2 1

Iostreams library question
by Lisa Glendenning 18 Aug '05

18 Aug '05

Hello, I just recently began using the boost iostreams library, and I can't figure out a way to see if a file has been successfully opened. E.g., I would like to reproduce this behavior: std::ofstream file("filename"); if(!file) { // error opening file } Thanks, Lisa Glendenning

2 1

[serialization][1.33.0?] xml_iarchive leak
by Jeff Flinn 18 Aug '05

18 Aug '05

Robert, The following code leads to numerous leaks when lIn's contents are not an xml_archive. Any thoughts on the cause? try { std::ifstream lIn( lpszPathName ); if( lIn.good() ) { boost::archive::xml_iarchive ia( lIn ); } } catch( boost::archive::xml_archive_exception& aExc ) { std::string lErr = aExc.what(); } Thanks, Jeff Flinn

4 13

Range + fixed_string
by Martin 18 Aug '05

18 Aug '05

I have a project that uses the fixed_string library (which is still in the review que). This library worked fine with string_algo in boost 1.32 but not with boost 1.33. I traced the problem to be the following template <typename StringT> struct C { typedef range_result_iterator<StringT>::type range_iterator_type; typedef StringT::iterator iterator_type; BOOST_STATIC_ASSERT((is_same<range_iterator_type, iterator_type>::value)); int dummy; }; main() { C<std::string> a; // ok C<array<char, 5> > b; // ok C<const_string<> > c; // ok C<vector<char> > d; // ok C<fixed_string<10> > e; // static assert } Didn't find any obvious reason in any of the libraries involved. Is it a problem with the VC70 compiler? (Also noticed that the range library copied a lot from the string_algo library e.g. BOOST_STRING_TYPENAME and code layout. Doesn't matter but it confused me sometimes about what library source I was looking at)

2 1

[serialization] how for a particular object to get ID that is assigned by the lib
by Ivan 18 Aug '05

18 Aug '05

Hi, How could I determine the objectID of an object after it's been saved? I mean the ID that boost::serialization generates for each object at saving. In other words - I know the address of the object and I would like to get its ID after it's been saved. Does anyone know how to do that? Example follows at the end. Ivan #include <boost/archive/text_oarchive.hpp> class A { template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & i; } public: int i;| }; int main() { std::ofstream ofs("filename"); boost::archive::text_oarchive oa(ofs); A a; a.i = 1; oa & a; // need ID of *a* here !!! }

2 1

Re: [Boost-users] thread safety of the mutex ctor
by James E Taylor 18 Aug '05

18 Aug '05

Are you sure there are no guarantees for function scope statics? I think the following is thread safe: void my_func() { static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_lock(&m); // do something once pthread_mutex_unlock(&m); } because the C-style PTHREAD_MUTEX_INITIALIZER doesn't involve a constructor call: the static is initialised before _any_ threads are running. Also, constructors of global statics are not guaranteed to be single-threaded for the same reason you can't safely reference one static from the constructor of another (The Static Initialisation Order Fiasco); one constructor could create a thread that goes and uses an uninitialised static, whilst the main thread tries to initialise it. Do you know whether the mutex ctor is thread-safe? T. Scott Urban <scottu(a)apptechsys.com> wrote : > On Thu, 2005-08-18 at 06:22 +1000, Christopher Hunt wrote: > > On 18/08/2005, at 1:19 AM, boost-users-request(a)lists.boost.org > wrote: > > > > > I envisage two threads accessing a function like this > concurrently: > > > > > > template<typename T> > > > boost::shared_ptr<T> > > > my_func() > > > { > > > static boost::mutex m; > > > boost::mutex::scoped_lock l(m); > > > > > > static boost::shared_ptr<T> p(new T); > > > return p; > > > } > > > > > > and my worry is that both threads could attempt to do the static > > > initialisation of m concurrently. Is there protection against this? > > > > Is it even possible to protect against this? > > The scope of m is actually outside of your function given that it is > > static. Thus it will be initialised outside of your function generally > > before any other threads get to start up. > > The scope of m is in the function, not global, but it has static > duration. Unlike a global, m will only be constructed if my_func() is > ever called in your program. > > That should set of warning bells in you brain. > > I don't believe there are any guarantees about the thread safety of the > initialization of function scope statics. This applies not just to the > mutex class in question but any type. A particular compiler might make > this usage thread safe - or maybe only guarantee initialization of basic > types - but I don't know if it's covered by the pthread spec - and > that's not helpful anyway to boost users, in general. And of course, > the C++ standard is as usual silent on the matter. > > You can make the mutex global - anonymous namespace or whatever. Since > global initializations are single threaded, you trade the threading > problem for the loss of on-demand resource usage. > > Another way to deal with this kind of problem is to use a modified > singleton pattern, but to make that thread safe, you need another mutex > (unless you want to risk DCL), so seems kind of pointless for this > instance. > > > > > > -- > t. scott urban <scottu(a)apptechsys.com> -- James E Taylor james(a)onalog.net ___________________________________ NOCC, http://nocc.sourceforge.net

2 1

boost 1.32: read_write_mutex assertion
by Slawomir Lisznianski 18 Aug '05

18 Aug '05

Hello, I'm using Boost.Threads read/write mutex with the writer scheduling priority. Under heavy load, from many threads, I'm getting the following assertion: <..>/boost/boost_1_32_0/libs/thread/src/read_write_mutex.cpp:190: void boost::deta il::thread::read_write_mutex_impl<Mutex>::do_write_lock() [with Mutex = boost::mutex]: Assertion `++loop_count == 1' failed. Abort (core dumped) The system is Linux kernel 2.4.21 (SMP) with 4 CPUs (Intel XEON MP) and g++ 3.2.3 20030502 (Red Hat Linux 3.2.3-42). Has anyone else experienced a similar problem? Thanks, Slawomir

2 2