August 2005 - Boost-users - lists.boost.org

[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

Re: [Boost-users] Boost 1.33.0 released
by Randy Bowen 18 Aug '05

18 Aug '05

I recall talk some time ago that the current Boost.Tuple library was going to be replaced by a TR1 compliant version, possibly that from the Fusion package in Spirit. Is that still the plan for the future? > > Boost 1.33.0 > ------------ > > New Libraries > > * Iostreams Library: Framework for defining streams, stream > buffers and i/o filters, from Jonathan Turkanis. > * Functional/Hash Library: A TR1 hash function object that can be > extended to hash user defined types, from Daniel James. > * Parameter Library: Write functions that accept arguments by > name: especially useful when a function has more than one > argument with a useful default value, since named arguments can > be passed in any order. > * Pointer Container Library: Containers for storing heap-allocated > polymorphic objects to ease OO-programming, from Thorsten Ottosen. > * Wave: Standards conformant implementation of the mandated > C99/C++ preprocessor functionality packed behind an easy to use > iterator interface, from Hartmut Kaiser. >

2 1

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

18 Aug '05

Thanks, that makes sense. Ben Hutchings <ben.hutchings(a)businesswebsoftware.com> wrote : > James E Taylor wrote: > > >I hope this isn't a stupid question, but.... > > > >Is the boost mutex constructor thread-safe? > > > > > Clearly it's unsafe for multiple threads to call a constructor on the > same block of memory concurrently. To answer the real question, dynamic > initialisation of local static variables is generally not thread-safe. > > >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? > > > >I've tried to use boost::call_once, which would give sufficient guarantees > but it's quite inflexible as nothing can be passed to or from the function > being called. > > > > > I don't see that there's any other way to do this using current C++ and > Boost. > > Ben. > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users -- James E Taylor james(a)onalog.net ___________________________________ NOCC, http://nocc.sourceforge.net

1 0

Problems Compiling boost
by gbonfim＠quality.com.br 18 Aug '05

18 Aug '05

I'm starting with boost library and have some problems and doubts. First, i'd like to know if i can compile boost only with bjam or there is other way. I'm trying to do that on linux, but without success. Anybody could explain me better how to use boost library in a project in c++ on linux that i have alredy created? Thanks for the help, Gustavo

3 2