- Boost - lists.preview.boost.org

[1.38.0] Beta under construction; branches/release closed
by Beman Dawes 27 Jan '09

27 Jan '09

The beta release is under construction. Please do not make any further commits to branches/release. Thanks, --Beman

1 0

[crypto] Feed Back
by Kasra 26 Jan '09

26 Jan '09

Hi, Since I have uploaded boost.crypto library on the vault there has been fare amount of downloads. I just wanted to see if anyone would like to give some feedback on the design of the library. With Best Regards Kasra

1 0

[msm] Gauging interest
by Christophe Henry 26 Jan '09

26 Jan '09

Hi, Msm has been in the Vault since a few months now and has been downloaded quite a few times, so it looks like there is interest in such a state machine framework, but I would prefer to be sure before requesting a formal review. So my question is, is there interest from the Boost community in Msm becoming part of Boost? Regards, Christophe

6 5

[threadpool] draft n2276 - launch_in_pool
by Oliver Kowalke 25 Jan '09

25 Jan '09

Hello, I did a look into draft n2276 - a launch_in_pool function is suggested (passing task to a system provided threadpool). Is it reasonable to have a static threadpool? How many worker-threads should this pool contain and how are the submitted tasks queued (FIFO, priority order ... unlimited/limited number of tasks can bes stored). What about applications which require a pool with different configuration than the static pool provides? Is it acceptable to pay for an unused pool? regards, Oliver -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

5 7

[thread/interprocess] could we improve recursive_mutex constructor
by vicente.botet 24 Jan '09

24 Jan '09

Hi, the recursive_mutex constructor initialize/set/destroy the pthread_mutexattr_t every time. I'm wondering if we can improve the efficiency storing this on a static variable which will be initialized once. What could be the better way to initialize this static variable? Note: the same applies to interprocess mutexes. recursive_mutex() { // begin code that can be initialized only once pthread_mutexattr_t attr; int const init_attr_res=pthread_mutexattr_init(&attr); if(init_attr_res) { throw thread_resource_error(); } int const set_attr_res=pthread_mutexattr_settype(&attr,PTHREAD_MUTEX_RECURSIVE); if(set_attr_res) { throw thread_resource_error(); } // end code that can be initialized only once int const res=pthread_mutex_init(&m,&attr); if(res) { throw thread_resource_error(); } // begin code that can be removed BOOST_VERIFY(!pthread_mutexattr_destroy(&attr)); // end code that can be removed } Regards, Vicente

2 2

[sandbox] Is the sandbox open to anyone
by Sid Sacek 24 Jan '09

24 Jan '09

Is the sandbox open to anyone for code submission, or is there a more complicated process before being able to submit libraries? Regards, -Sid

4 4

[thread] Why the at_thread_exit cleanup function be const?
by vicente.botet 24 Jan '09

24 Jan '09

In addition, if a remove the const on operator()() struct mycallable1 { void operator()() { std::cout << "mycallable1" << std::endl; }; }; void my_thread() { std::cout << "my_thread" << std::endl; mycallable1 x; boost::this_thread::at_thread_exit(x); } I get the following error: gcc.compile.c++ ..\..\..\bin.v2\libs\interthreads\test\hello_world.test\gcc-4.3.2\debug\target-os-cygwin\threadapi-pthread\threading-multi\hello_world.o ../../../boost/thread/detail/thread.hpp: In member function `void boost::detail::thread_exit_function<F>::operator()() const [with F = mycallable1]': ..\example\hello_world.cpp:52: instantiated from here ../../../boost/thread/detail/thread.hpp:474: error: passing `const mycallable1' as `this' argument of `void mycallable1::operator()()' discards qualifiers Why the cleanup function must be const? Best, Vicente ______________________ Vicente Juan Botet Escribá

2 2

[1.38][flyweight] permission request to merge
by JOAQUIN M. LOPEZ MUÑOZ 24 Jan '09

24 Jan '09

Hi, Given that some dealy has been incurred with respect to the official Boost 1.38 release roadmap, I don't know if I'm in time to merge the following change in Boost.Flyweight to branches/release (two days in trunk without regressions): https://svn.boost.org/trac/boost/changeset/50709 Do I have permission? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

sql_cli and other database-related libraries
by Sergey Sadovnikov 23 Jan '09

23 Jan '09

Hello All, There is sql_cli library in the boost sandbox. What is the review and submission status of this (or another same) library? -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru

1 0

[1.38] 1.38 blurb
by JOAQUIN M. LOPEZ MUÑOZ 23 Jan '09

23 Jan '09

Hello, Am I mistaken, or is the news entry for the upcoming Boost.138 version in a poor state? http://tinyurl.com/dftnsc Shouldn't authors be publishing the updates and inclusions of new libs here? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Vault: still needed?
by David Abrahams 23 Jan '09

23 Jan '09

Hi All, For some time now, Boostpro Computing has been hosting the Boost file valut, but now that Boost has a great Subversion host I'm beginning to wonder whether the vault is still needed. What's the case for holding onto it when people could just check their speculative work into the sandbox and subsequently merge smoothly into the Boost trunk if it is accepted? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

11 28

[1.38] Documentation - Changes in this release
by vicente.botet 23 Jan '09

23 Jan '09

Hi, I would like to start checking the documentation for the 1.38 release. I have download the one of the comressed files in http://boost.cowic.de/rc/ from the 21th January. Is this the correct address to inspect? When we can expect to see the section Change in this release completed? Thanks, Vicente

2 1

Old library version?
by Kowalke Oliver (QD IT PA SI) 23 Jan '09

23 Jan '09

Hello, I need boost 1.33.1 but it seams it is not available from the website anymore? Regards, Oliver

2 1

Re: [boost] [crypto] Ready as a debug library.
by Kasra 23 Jan '09

23 Jan '09

Hi, The boost.crypto library is on the vault at: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_… Anyone: How could i access the boost svn?? With Best Regards Kasra

1 0

[thread] thread_specific_ptr optimizations
by Ioannis Papadopoulos 22 Jan '09

22 Jan '09

I was looking into the actual implementation of thread_specific_ptr and saw that there are actually two implementations, a generic one that uses the pthread facilities for TLS and the other one some VC-based one (I'm sorry, I'm not that proficient with MS products). I don't know if people are aware of WG21 N2659, it is the proposal for TLS (thread local storage) in C++0x http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2008/n2659.htm Everyone that is using POSIX getthreadspecific and setthreadspecific (that are being currently used in thread_specific_ptr) knows that they are slower than what a compiler provides. Is there any thought of actually using any of the compiler-provided keywords to remove the need for the POSIX functions and speeding up boost::thread::get_current_thread_data()?

1 0

manipulators for filtering_stream s
by Roland Schwarz 22 Jan '09

22 Jan '09

Surprisingly I was not able to find on the net code that would give me a smart way to indent a stream. So I wrote a little filter based on the boost iostreams library. My first attempt was: boost::iostreams::filtering_ostream out; indent_filter ind(4); out.push(ind); out.push(std::cout); However trying to control it via e.g. ind.in() ind.out() turns out to be problematic interface since, 1) out.push() takes a copy of ind 2) the interface ind.in() is suboptimal. With my attached example it is possible to: #include "indent.hpp" ... boost::iostreams::filtering_ostream out; indent_filter::push(out,2); out.push(std::cout); ... And use it like so: out << "Hello Filter!\n" << indent_in << "this is\n" << "indented\n" << indent_out << "until here\n" ; Which will result in output: Hello Filter! this is indented until here The state is stored in the ios base class of the stream, by way of the pword mechanism. Consequently the filter stream even may be downcast to a basic_ostream, and the indenter will still work. E.g. with out defined as above: ... foo(out); ... void foo(std::ostream& out) { out << indent_in << "out is a downcast filter_stream\n" << indent_out << "end of indentation\n" ; } If you want to try it out, you just need to include the header indent.hpp. If someone thinks the snippet is usable either as an example for the iostreams library or the filter streams manipulator idea is worth generalizing to make it usable for other filters too, I would be glad to hear from you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

5 17

[OT?] SIMD and Auto-Vectorization (was Re: How to structurate libraries ?)
by Dean Michael Berris 22 Jan '09

22 Jan '09

On Sat, Jan 17, 2009 at 5:33 PM, Joel Falcou <joel.falcou(a)u-psud.fr> wrote: > David A. Greene a écrit : >> >> Ahem: http://www.cray.com > > Two points : > 1/ Not everyone has access to a cray-like machine. Parallelization tools for > CotS machines is not to be neglected and, on this front, lots of thing need > to be done What do you mean by parallelization for CotS (Commodity off-the Shelf) machines? I personally have dealt with two types of parallelization: parallelization at a high level (dealing with High Performance Computing using something like MPI for distributed message-passing parallel computation across machines) and parallelization at a low level (talking about SSE and auto-vectorization). If you mean dealing with high level parallelism across machines, you already have Boost.MPI and I suspect you don't intend to replace that or tackle that kind of parallelism at the large scale. If you mean dealing with parallelism within a program, then you already have Boost.Thread and Boost.Asio (with the very nice io_service object to be able to use as a job-pool of sorts run on many threads). At a lower level, you then have the parallel algorithm extensions to the STL already being shipped by compiler vendors (free and commercial/prioprietary) that have parallel versions of the STL algorithms (see GNU libstdc++ that comes with GCC 4.3.x and Microsoft's PPL). > 2/ vector supercomputer != SIMD-enabled processor even if the former may > include the later. Actually, a vector supercomputer is basically a SIMD machine at a higher level -- that's if I'm understanding my related literature correctly. >> >> Auto parallelization has been around since at least the '80's in >> production machines. I'm sure it was around even earlier than that. >> > > What do you call auto-parallelization ? > > Are you telling me that, nowaday , I can take *any* source code written in C > or C++ or w/e compile it with some compiler specifying --parallel and > automagically get a parallel version of the code ? If so, you'll have to > send a memo to at least a dozen research team (including mine) all over the > world so they can stop trying working on this problem and move on something > else. Should I also assume than each time a new architecture comes out, > those compilers also know the best way to generate code for them ? I beg to > differ, but automatic parallelization is far from "done". > You might be surprised but the GNU Compiler Collection already has -ftree-vectorize compiler flag that will do analysis on the IR (Intermediate Representation) of your code and generate the appropriate SSE/SSE2/SSE3/MMX/... for your architecture. They advise adding -msse -msse2 for x86 platforms to the flags. Although I don't think you should stop with the research for better ways to do automatic vectorization, I do however think that doing so at the IR level at the compiler would be more fruitful especially when combined with something like static analysis and code transformation. You might even be surprised to know that OpenCL (the new framework for dealing with heterogeneous scalable parallelism) even allows for run-time transformation of code that's meant to work with that framework -- and Apple's soon-to-be-released new version of its operating system and compiler/SDK will be already supporting. > Then again, by just looking at the problem of writing SIMD code : explain > why we still get better performance for simple code when writing SIMD code > by hand than letting gcc auto-vectorize it ? Because GCC needs help with auto-vectorization, and that GCC is a best-effort project (much like how Boost is). If you really want to see great auto-vectorization numbers, maybe you can try looking at the Intel compilers? Although I haven't personally gotten (published and peer-reviewed) empirical studies to support my claim, just adding auto-vectorization in the compilation of the source code of the project I'm dealing with (pure C++, no hand-written SIMD stuff necessary) I already get a significant improvement in performance *and* scalability (vertically of course). I think a "better" alternative would be to help the GCC folks do a better (?) job at writing more efficient tree-vectorization implementations and transformations that produce great SIMD-aware code built into the compiler. If somehow you can help with the pattern recognition of auto-vectorizable loops/algorithms from a higher level than the IR level and do source-level transformation of C++ (which I think would be way cool BTW, much like how the Lisp compilers are able to do so) to be able to produce the right (?) IR for the compiler to better auto-vectorize, then *that* would be something else. Maybe you'd also like to look at GCC-ICI [0] to see how you can play around with extending GCC then it comes to implementing these (admittedly if I may say so) cool optimizations of the algorithms to become automatically vectorized. >> >> Perhaps your SIMD library could invent convenient ways to express those >> idioms in a machine-independent way. >> > > Well, considering the question was first about how to structure the group of > library i'm proposing, > > I apologize to not having taken the time to express all the features of > those libraries. Moreover, even with a simple example, the fact that the > library hides the differences between SSE2,SSSE3,SSE3,SSE4,Altivec,SPU-VMX > and the forecoming AVX is a feature on its own. Oh, and as specified in the > former mail, the DSL take care of optimizing fused operation so thing like > FMA are detected and replaced by the proper intrinsic when possible. Same > with reduction like min/max, operations like b*c-a or SAD on SSEx. I think I understand what you're trying to achieve by adding a layer of indirection at the library/code level -- however I personally think (and have read through numerous papers already, while doing my research about parallel computing earlier in my student days) that these optimizations/transformations are best served by the tools that create the machine code (i.e. compilers) rather then dealt with at the source code level. What I mean by this is that even though it's technically possible to implement a "parallel C++ DSEL" (which can be feasibly achieved now with Boost.Proto and taking some lessons with attribute grammars [1] and how Spirit 2(x?) with a combination of Boost.Phoenix does it) it would be reaching a bigger audience and serving a larger community if the compilers became smarter at doing the transformations themselves, rather than getting C++ developers to learn yet another library. > > Anyway, we'll be able to discuss the library in itself and its features when > a proper thread for it will start. > Maybe we can discuss it in this one? :D HTH References: [0] http://gcc-ici.sourceforge.net/ [1] http://en.wikipedia.org/wiki/Attribute_grammar -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

10 29

[crypto] Ready as a debug library.
by Kasra 22 Jan '09

22 Jan '09

Hi all, The crypto library that I have been talking about is somehow ready to be seen and reviewed for suggestions and etc. So I will loads on the vault for interested parties. Kasra

3 2

[thread] proposal to manage portable and non portable thread attributes
by vicente.botet 22 Jan '09

22 Jan '09

Hello, Boost.thread has already a non portable interface to get the thread handle class thread { public: ... typedef np_native_handle_type native_handle_type; native_handle_type native_handle(); ... }; Boost.Thread do not allow to pass thread attributes on the thread constructor. I supose that this is due to portable issues. Could we identifiy which attributes are portable and which one not? The portable attributes (as stack size, ...) can be grouped on a thread_attributes class. In order to be able to pass whatever attribute to the thread constructor we can add the setting of non portable attributes to this thread_attributes class, and making the thread constructor take a thread_attributes in addition to the existing parameters. class thread { public: class thread_attributes { // portable attributes public: // set/get of attributes // .. #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) private: pthread_attr_t native_attributes; public: set_np_attributes(const pthread_attr_t* h); // ... other #else #error "Boost threads unavailable on this platform" #endif }; thread(const thread_attributes*p, F f,A1 a1); ... }; The portable application needing some specific configuration can construct portable threads using the following schema thread::thread_attributes attr; // set portable attributes // ... #if defined(BOOST_THREAD_PLATFORM_WIN32) // ... window version #elif defined(BOOST_THREAD_PLATFORM_PTHREAD) // ... pthread version pthread_attr_t native_attributes; pthread_attr_init(&native_attributes); pthread_attr_setstacksize(&native_attributes, 1000000); attr.set_np_attributes(&native_attributes); #else #error "Boost threads unavailable on this platform" #endif thread th(attr, f,ctx); What do you think? Vicente

3 3

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