- Boost - lists.boost.org

A set of individual libraries vs. One big library
by Anis Benyelloul 22 Jan '09

22 Jan '09

Hello, I was wondering if there was any interest into making the boost libraries more ``independent''? Boost contains many libraries with very different application domains. In most cases you'll want to use only one/two libraries in your project (without having to carry the whole boost code base around). But: - The files in the boost tarball are organized as if boost was a single big library: All the headers in `/boost' and all the source files together ... etc - The header file dependencies are unclear... it makes very difficult to ``extract'' just the library you need from the tarball (it is not enough to copy the directory whose name matches the library you want) It would be nice to handle this in a way similar to how ``packages'' are handled on modern Linux systems: - Each library (header+source+doc+test/..) in one directory/package (instead of having all the headers from all the libraries in the same dir, and all the tests in the same directory, all the documentation in another... etc) - A clear/automated way to handle dependencies between packages. This would help spot the ``common services'' (like boost.config) that so many libraries rely on. I think having the tarball organized in terms of individual libraries (instead of a single big one) should be the default as it make more sens from a user perspective. What do you think? Reguards, - Anis

12 24

Compilation errors upgrading boost from 1.34 to 1.37 (Windows)
by mborghi2 22 Jan '09

22 Jan '09

Dear all, I've just upgraded the boost library from 1.34 to 1.37 on Windows. When I try to compile our software with the new library version (both with VS 7.0 and with VS 9.0) I meet 2 different kind of problems. In our software we instantiate the class boost::recursive_mutex::scoped_lock (instance of the template unique_lock), and one problem seems that the class boost::recursive_mutex doesn't implement the function unlock_upgrade_and_lock. I'm compiling the code settings the define BOOST_THREAD_WIN32, I don't know if there are others defines to be specified. Follow the VS 9.0 output (with the compilation errors): ... 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(406) : warning C4661: 'boost::unique_lock<Mutex> &boost::unique_lock<Mutex>::operator =(boost::upgrade_lock<Mutex> &)' : no suitable definition provided for explicit template instantiation request 1> with 1> [ 1> Mutex=boost::recursive_mutex 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(215) : see declaration of 'boost::unique_lock<Mutex>::operator =' 1> with 1> [ 1> Mutex=boost::recursive_mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(406) : warning C4661: 'boost::unique_lock<Mutex> &boost::unique_lock<Mutex>::operator =(boost::upgrade_lock<Mutex> &)' : no suitable definition provided for explicit template instantiation request 1> with 1> [ 1> Mutex=boost::mutex 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(215) : see declaration of 'boost::unique_lock<Mutex>::operator =' 1> with 1> [ 1> Mutex=boost::mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(406) : warning C4661: 'boost::unique_lock<Mutex> &boost::unique_lock<Mutex>::operator =(boost::upgrade_lock<Mutex> &)' : no suitable definition provided for explicit template instantiation request 1> with 1> [ 1> Mutex=boost::recursive_timed_mutex 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(215) : see declaration of 'boost::unique_lock<Mutex>::operator =' 1> with 1> [ 1> Mutex=boost::recursive_timed_mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(786) : error C2039: 'unlock_upgrade_and_lock' : is not a member of 'boost::recursive_mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\win32\recursive_mutex.hpp(22) : see declaration of 'boost::recursive_mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(780) : while compiling class template member function 'boost::unique_lock<Mutex>::unique_lock(boost::detail::thread_move_t<T>)' 1> with 1> [ 1> Mutex=boost::recursive_mutex, 1> T=boost::upgrade_lock<boost::recursive_mutex> 1> ] 1> d:\masterfinancedevl\admindevl\devl\src\include\mfcoreutility\mutexwrapper.h(114) : see reference to class template instantiation 'boost::unique_lock<Mutex>' being compiled 1> with 1> [ 1> Mutex=boost::recursive_mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(786) : error C2039: 'unlock_upgrade_and_lock' : is not a member of 'boost::mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\win32\mutex.hpp(22) : see declaration of 'boost::mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(780) : while compiling class template member function 'boost::unique_lock<Mutex>::unique_lock(boost::detail::thread_move_t<T>)' 1> with 1> [ 1> Mutex=boost::mutex, 1> T=boost::upgrade_lock<boost::mutex> 1> ] 1> d:\masterfinancedevl\admindevl\devl\src\include\mfcoreutility\mutexwrapper.h(129) : see reference to class template instantiation 'boost::unique_lock<Mutex>' being compiled 1> with 1> [ 1> Mutex=boost::mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(786) : error C2039: 'unlock_upgrade_and_lock' : is not a member of 'boost::recursive_timed_mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\win32\recursive_mutex.hpp(42) : see declaration of 'boost::recursive_timed_mutex' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(780) : while compiling class template member function 'boost::unique_lock<Mutex>::unique_lock(boost::detail::thread_move_t<T>)' 1> with 1> [ 1> Mutex=boost::recursive_timed_mutex, 1> T=boost::upgrade_lock<boost::recursive_timed_mutex> 1> ] 1> d:\masterfinancedevl\admindevl\devl\src\include\mfcoreutility\mutexwrapper.h(144) : see reference to class template instantiation 'boost::unique_lock<Mutex>' being compiled 1> with 1> [ 1> Mutex=boost::recursive_timed_mutex 1> ] 1>d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\win32\basic_recursive_mutex.hpp(64) : error C2679: binary '+' : no operator found which takes a right-hand operand of type 'const boost::xtime' (or there is no acceptable conversion) 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\posix_time\date_duration_operators.hpp(31): could be 'boost::posix_time::ptime boost::posix_time::operator +(const boost::posix_time::ptime &,const boost::gregorian::months &)' [found using argument-dependent lookup] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\date_duration_types.hpp(132): or 'boost::gregorian::date boost::date_time::months_duration<base_config>::operator +(const boost::gregorian::date &,const boost::date_time::months_duration<base_config> &)' [found using argument-dependent lookup] 1> with 1> [ 1> base_config=boost::gregorian::greg_durations_config 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\posix_time\date_duration_operators.hpp(75): or 'boost::posix_time::ptime boost::posix_time::operator +(const boost::posix_time::ptime &,const boost::gregorian::years &)' [found using argument-dependent lookup] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\date_duration_types.hpp(244): or 'boost::gregorian::date boost::date_time::years_duration<base_config>::operator +(const boost::gregorian::date &,const boost::date_time::years_duration<base_config> &)' [found using argument-dependent lookup] 1> with 1> [ 1> base_config=boost::gregorian::greg_durations_config 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\time.hpp(138): or 'boost::posix_time::ptime boost::date_time::base_time<T,time_system>::operator +(const boost::date_time::date_duration<duration_rep_traits> &) const' 1> with 1> [ 1> T=boost::posix_time::ptime, 1> time_system=boost::posix_time::posix_time_system, 1> duration_rep_traits=boost::gregorian::date_duration_rep 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\date_time\time.hpp(158): or 'boost::posix_time::ptime boost::date_time::base_time<T,time_system>::operator +(const boost::posix_time::time_duration &) const' 1> with 1> [ 1> T=boost::posix_time::ptime, 1> time_system=boost::posix_time::posix_time_system 1> ] 1> while trying to match the argument list '(boost::system_time, const boost::xtime)' 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(364) : see reference to function template instantiation 'bool boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::timed_lock<boost::xtime>(const Duration &)' being compiled 1> with 1> [ 1> underlying_mutex_type=boost::detail::basic_timed_mutex, 1> Duration=boost::xtime 1> ] 1> d:\masterfinancedevl\admindevl\devl\ext70\inc\boost7.1\boost\thread\locks.hpp(363) : while compiling class template member function 'bool boost::unique_lock<Mutex>::timed_lock(const boost::xtime &)' 1> with 1> [ 1> Mutex=boost::recursive_mutex 1> ] ... Have you any suggestion on how to solve our compilation problem? thanks in advance best regards Matteo -- View this message in context: http://www.nabble.com/Compilation-errors-upgrading-boost-from-1.34-to-1.37-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] Should we PING the ML when there is no answer at all to a post?
by JOAQUIN M. LOPEZ MUÑOZ 21 Jan '09

21 Jan '09

_______________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de vicente.botet [vicente.botet(a)wanadoo.fr] Enviado el: miércoles, 21 de enero de 2009 19:55 Para: boost(a)lists.boost.org Asunto: [boost] Should we PING the ML when there is no answer at all to a post? > > Hi, > > sometimes the posts are not answered at all, either because there is no interest, > or because the post is lost between the others. > > I would like to know if it is a good idea to PING the ML when there is no answer at > all to a post. I've done it several times in the past and got no reprimand from the moderators, so I guess it's OK to do it with some restraint. > If yes, how and when this PING must be done? Repost the entire mail and add a [repost] prefix to the subject line. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Should we PING the ML when there is no answer at all to a post?
by vicente.botet 21 Jan '09

21 Jan '09

Hi, sometimes the posts are not answered at all, either because there is no interest, or because the post is lost between the others. I would like to know if it is a good idea to PING the ML when there is no answer at all to a post. If yes, how and when this PING must be done? Thanks, Vicente

1 0

[thread] locks.hpp double declaration of unique_lock(unique_lock&& other)
by vicente.botet 21 Jan '09

21 Jan '09

Hi in lines 248-255 of the file boost/thread/locks.hpp we found the unique_lock(unique_lock&& other) declaration twice one withoth explicit and defined and the other with explicit an undefined. #ifdef BOOST_HAS_RVALUE_REFS unique_lock(unique_lock&& other): m(other.m),is_locked(other.is_locked) { other.is_locked=false; other.m=0; } explicit unique_lock(upgrade_lock<Mutex>&& other); Could you say me why this is nesded? _____________________ Vicente Juan Botet Escribá

3 3

[iostreams] Error reporting for buffered streams
by Eric MALENFANT 21 Jan '09

21 Jan '09

By default, filtering_streams do buffering. This means that what is written to them does not necessarily reach the underliyng Filters and Device immediately. It is thus my understanding that, in order to be sure that all data was written, one should somehow flush the buffered data, and then check the stream state before closing it. As a first attempt, I tried flush(), but it does not seem to do what I expected. Looking at the docs, I then found what seemed to be what I was looking for: strict_sync(), whose documentation states that "A return value of true guarantees that all buffered data has been successfully forwarded.". Moreover, the FAQ entry "Can I swap Filters or Devices in the middle of a sequence of i/o operations?" seems to confirm this, as it says: "First call strict_sync. If it returns true, you can safely call set_auto_close(false) and pop one or more components without closing the stream. This applies to instances of filtering_stream, filtering_streambuf and chain." But again, this did not work: strict_sync() returns true although buffered data remains. Consider this contrived example: // A codecvt facet that always fails class always_fail_cvt : public std::codecvt<wchar_t,char,mbstate_t> { protected: virtual result do_out( state_type&, const intern_type*, const intern_type*, const intern_type*&, char* to, char*, char*&) const { return std::codecvt_base::error; } //... }; int main(int argc, char* argv[]) { std::wofstream fs("whatever"); fs.imbue(std::locale(fs.getloc(), new always_fail_cvt)); boost::iostreams::filtering_wostream s(fs); s << L"Hello"; std::cout << std::boolalpha << s.good() << ', '; s.flush(); std::cout << s.good(); return 0; } Running this (on Windows with MSVC 7.1) produces "true, true" The first "true", is not surprising, as the characters are buffered and code conversion has not taken place yet, but the second is. (to me at least). Considering the presence of strict_sync(), I assumed that the "forgiveness" of flush() is intentional, to allow stateful filters to retain buffered data, maybe. However, replacing the "s.flush();" line in the above program with "std::cout << s.strict_sync() << ", ";" does not seem to change things much. Even though a conversion failure occured and data remains buffered, strict_sync() returns true, and the stream's state is still good(). So, to sum up: 1) If my understanding of the semantics of strict_sync() is correct, it seems that indirect_streambuf::strict_sync() should verify that the buffer is empty after the call to sync_impl(), and fail if it is not the case. Something like this maybe: template<typename T, typename Tr, typename Alloc, typename Mode> bool indirect_streambuf<T, Tr, Alloc, Mode>::strict_sync() { try { // sync() is no-throw. sync_impl(); return obj().flush(next_) && ((pptr() - pbase()) == 0); // Added this --^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } catch (...) { return false; } } 2) Is it "correct" that filtering_stream::flush() does not completely flush without reporting an error? 3) Does this come from an incompatibility between Boost.IOStreams idea of error-reporting (throwing exceptions) and that of the std streambufs (returning EOF, mainly)? In particular, Boost.IOStreams writes in a wrapped std::streambuf by using sputn(), which, AFAI(don't)U, does not have a clear error reporting strategy. IOWs, should write_device_impl<streambuf_tag>::write() be modified so that it reports errors by an exception. Something like this maybe: template<typename T> static std::streamsize write (T& t, const typename char_type_of<T>::type* s, std::streamsize n) // { return t.sputn(s, n); } { std::streamsize count = t.sputn(s, n); if (count == n){ return count; } // If all characters could not be written, check if it is because of an error or only because of blocking if (T::traits_type::eq_int_type(t.sputc(s[count]), T::traits_type::eof())){ throw std::ios_base::failure("write error"); } else{ return count + 1; } } Sorry for the longish post, and thanks for reading up to here, Éric Malenfant

1 0

[random] A much faster Poisson variate generation
by Ross Levine 21 Jan '09

21 Jan '09

Hello, I have modified the poisson_distribution class to use an updated version of Ahrens and Dieter's PD algorithm for generating Poisson variates, as described in "Computer Generation of Poisson Deviates from Modified Normal Distributions." Is this allowed in Boost, and is there interest? The current algorithm is O(mean), while PD is bounded time. In addition, the current implementation fails for mean >> 750. PD does, however, use a lookup table and thus has a non-trivial constructor and needs 36 * sizeof(RealType) + 1 * sizeof(IntType) bytes per poisson_distribution object. Please let me know if this is desired. Ross

2 7

Re: [boost] A PP trick to define a synchronized block java-like macro
by JOAQUIN M. LOPEZ MUÑOZ 21 Jan '09

21 Jan '09

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Sebastian Redl [sebastian.redl(a)getdesigned.at] Enviado el: martes, 20 de enero de 2009 22:39 Para: boost(a)lists.boost.org Asunto: Re: [boost] A PP trick to define a synchronized block java-like macro > vicente.botet wrote: > > for (VARS DECLARATION, bool __continue=true; > > __continue; > > __continue=false) > > > > > I'm afraid this is not valid syntax. The first clause of the > for-statement is a for-init-statement, which can be either an expression > with a semicolon, or a simple-declaration. A simple-declaration lets you > declare any number of variables, but they must all have the same > declspec, i.e. the same fundamental type (with variations like "pointer > to", "array of" or "function returning"). The following variation would do: for (VARS DECLARATION, *continue_hlp_,**continue_=&continue_hlp_; continue_; continue_=0) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 6

[1.38.0][Spirit] char_class test failing on both trunk and release, all platforms
by Beman Dawes 21 Jan '09

21 Jan '09

The Spirit char_class test is failing on both trunk and release, all platforms. Any progress on fixing this? --Beman

2 1

[1.38.0] [config] Linux release branch link failures
by Beman Dawes 20 Jan '09

20 Jan '09

config_test is failing with link errors on both Linux testers. Any ideas? --Beman "g++" -o "/home/steve/Packages/boost/upstream/testing/release/results/boost/bin.v2/libs/config/test/config_test.test/gcc-4.3.3/debug/config_test" -Wl,--start-group "/home/steve/Packages/boost/upstream/testing/release/results/boost/bin.v2/libs/config/test/config_test.test/gcc-4.3.3/debug/config_test.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g /home/steve/Packages/boost/upstream/testing/release/results/boost/bin.v2/libs/config/test/config_test.test/gcc-4.3.3/debug/config_test.o: In function `boost_has_pthread_mutexattr_settype::f()': /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_pthread_ma_st.ipp:21: undefined reference to `pthread_mutexattr_init' /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_pthread_ma_st.ipp:23: undefined reference to `pthread_mutexattr_settype' /home/steve/Packages/boost/upstream/testing/release/results/boost/bin.v2/libs/config/test/config_test.test/gcc-4.3.3/debug/config_test.o: In function `boost_has_pthreads::test()': /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_pthreads.ipp:35: undefined reference to `pthread_mutex_trylock' /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_pthreads.ipp:44: undefined reference to `pthread_create' /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_pthreads.ipp:52: undefined reference to `pthread_join' /home/steve/Packages/boost/upstream/testing/release/results/boost/bin.v2/libs/config/test/config_test.test/gcc-4.3.3/debug/config_test.o: In function `boost_has_clock_gettime::f()': /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_clock_gettime.ipp:21: undefined reference to `clock_gettime' collect2: ld returned 1 exit status

3 3