January 2010 - Boost - lists.preview.boost.org

[Boost.utility]
by Andrew Chinkoff 27 Jan '10

27 Jan '10

Having considered [ http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt] I propose singleton implementation. I had attached "singleton.hpp" to this letter. Below is the test program: #include <stdio.h> #include <singleton.hpp> class A : public boost::Singleton<A> { // // Only Singleton class can create and delete us! // SINGLETON_IS_MY_FRIEND; public: void foo(){ printf("foo!\n"); } A(){ printf("A()\n"); } ~A(){ printf("~A()\n"); } }; void main() { // It is not compiled: //A a = A::Instance(); // That is exactly as it should be used: A::Instance().foo(); } Test program outputs: A() foo! ~A() I suggest include "singleton.hpp" into "utility.hpp" header that it can be used along with: boost::noncopyable, etc.

14 67

[1.41.0] [filesystem] Undefined references to get_system_category and get_generic_category
by Richard Hadsell 27 Jan '10

27 Jan '10

I am trying to build some code using the 1.41.0 version of the filesystem library. It used to build with version 1.34.1. I am getting errors, when the linker fails to find boost::system::get_system_category and boost::system::get_generic_category. What do I need to do differently to find or build these functions? -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

2 2

Are any of these bugs _really_ show stoppers?
by Marshall Clow 27 Jan '10

27 Jan '10

There are 25 bugs in the Trac system which are marked as "showstopper". Are any of these really worth holding up the release for? (and if not, should we reclassify these bugs?) http://svn.boost.org/trac/boost/report/29 986 Problem building Python modules on boost 1.34.0 1215 Boost 1.34.1, mpl: Wrong workaround detection using MinGW32 (or.hpp, line #33)" 2411 bzip2_compressor does not work with filtering_istream,new,Bugs,Boost 1.37.0 2512 interval cosh: wrong result if interval contains 0 (but is not identical to [0,0]) 2513 rint not present in Visual Studio 2008 2164 locate_root wrong under CygWin 2797 Two problems with thread_specific_ptr 2255 Compilation error during arm cross compile - boost 1.36 2883 Boost::signals compile problem with GCC 3.4.5 2958 [patch] changes to make asio compile on vxWorks 2956 vxWorks POSIX quirks for date_time 583 Fixes for build on IBM pSeries for AIX and Linux 426 lambda vs pure virtual functions 3325 Limited support for mapping regions to specific addresses in Linux 738 Memory leaks with signal::connect? 3480 Build fails on Debian: 2.6.18-5-686-bigmem #1 SMP Tue Dec 18 22:34:10 UTC 2007 i686 GNU/Linux 3165 wrong project-config.jam generated for intel-linux 2955 [patch] recursive mutex impossible if pthread_mutexattr_settype not defined 1066 Patch to make Boost.Python compile on SunCC 2185 bjam hangs when building libs/python/examples/quickstart under MacOS X 3716 Application crash when using Boost.Python in a plug-in DLL for that application 3723 gzip_docompressor error - basic_array_source no putback member 2330 thread::interrupt() can be lost if condition_variable::wait() in progress 3735 thread_group::interrupt_all() is unreliable 2226 boost::thread 1.36.0 /clr Link Error LNK2022 Just asking.... -- Marshall P.S. I don't mind fixing 2512 and 2513 - and can do that for 1.43 if people don't want them in 1.42.

3 4

BoostCon Conference Hotel Now Accepting Reservations
by David Abrahams 26 Jan '10

26 Jan '10

Hello Boosters and former BoostCon attendees! The BoostCon website has been updated for 2010, registration is open, and the conference hotel is already prepared to start taking our reservations. If you are planning to go to Boostcon this year, I suggest you take a few minutes to register (http://www.boostcon.com/registration) and make your hotel reservation (http://www.boostcon.com/location/lodging) today. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

1 0

[chrono] v0.3.2 New frequency, lifetime and percentage stopwatch_accumulator features
by vicente.botet 26 Jan '10

26 Jan '10

Hi, I have update the Boost.Chrono library with some minor features, a lot of bug fixes, and started the tutorial with some examples of features interesting people since the last version. New Features: * Added overloading for operator/(Integer/Duration) (used to get the frequency) * Added frequency, lifetime and percentage to the stopwatch_accumulator. The default format is "%c times, sum%ss, min%ms, max%Ms, mean%as, frequency%fherzs, lifetime%ls, percentage=%p%\n", where %c : the counter of the number of times the pair start/stop has been called. %s : the sum of the samples of elapsed time between the call to start/stop. %m : the min of the samples of elapsed time between the call to start/stop. %M : the max of the samples of elapsed time between the call to start/stop. %a : the mean of the samples of elapsed time between the call to start/stop. %f : the frequency of calls to start. %l : the lifetime of the stopwatch_accumulator. %p : the percentage of time spent by this stopwatch respect to its lifetime. Bug Fixes * Specific formatters didn't work completly * Replace duration(0) by duration::zero() on template classes. * suspend didn't work: partial_ not initialized neither taken in account by the elapsed function. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. SVN repository http://svn.boost.org/svn/boost/sandbox/chrono. I would like to thanks particularly Andrew Chinkoff for his suggestion of the frequency feature and all those that have tried the library and reported the bugs they found, either on this ML or personally. I would really appreciate if people having the possibility to test on other platforms/compilers report me how the library works. As you can see the library is already on the review schedule, waiting for a review manager and a date for the review. I expect to add yet some features for the review release as thread clocks, and suspensible clocks i.e. clocks that can be suspended/resumed. Any idea for better naming the concepts/classes is welcome. Hoping this release works better for you, Vicente (See below the contents of preceding releases) ----- Original Message ----- From: "vicente.botet" <vicente.botet(a)wanadoo.fr> To: <boost-users(a)lists.boost.org>; <boost(a)lists.boost.org> Sent: Wednesday, January 20, 2010 11:02 PM Subject: [chrono] v0.3.1 Support for wide characters Hi, this new version includes: * Added support for wide characters on formatters. * Added chrono.hpp and stopwatches.hpp header files at the boost level. * Update of the doc taking care of preceding comments. Comments are welcome :) Best, Vicente ----- Original Message ----- From: "vicente.botet" <vicente.botet(a)wanadoo.fr> To: <boost(a)lists.boost.org>; <boost-users(a)lists.boost.org> Sent: Sunday, January 17, 2010 9:14 PM Subject: [chrono] v0.3 New Stopwatch Feature Hi, I'm pleased to announce the new version of the Boost.Chrono library. The implementaton is quite stable; the new interface could suffer of some modifications, renaming, ... as far as you submit some proposals. I would request a formal review soon and I will need a review manager. I know that review managers are hard to find, so if you are interested in the library, please the Review Wizards. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. I've tested it with gcc and MSVC. Previoous version of the library have been testted on Mac, but I'm not able to test this platform. Could someone check if there are some regressions on Mac? New Features: * Process cpu clocks * Independent process cpu clocks for real, user, system process CPU time * Global process cpu clock for real, user, system process CPU time * Stopwatch concept measuring elapsed time between different points in time associated to the operations start, stop, suspend and resume. * stopwatch is a model Stopwatch measuring the elapsed time between the start and the stop operations. * stopwatch_accumulator is a model Stopwatch allowing to accumulate several time samples and give the average, ... * Scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * Stopwatch Formatter concept * stopwatch formatter "%ds\n" * stopwatch accumulator formatter "%c times, sum%ss, min%ms, max%Ms, mean%as\n" * time formatter "real %rs, cpu %cs (%p%), user %us, system %ss\n" * digital_time decomposition class separating days, hours,minutes,seconds, nanoseconds from any duration class (looking for a better name) * digital_time formatter "%d days(s) %h:%m:%s.%n\n" * stopwatch_reporter is a convenient generic class reporting elapsed time for the Stopwatch concept. * stopclock<Clock> shortcut stopwatch_reporter<stopwatch<Clcok>> * typeof registration for classes duration and time_point Depreceated Features: * The classes process_times, process_clock, process_timer, timer and run_timer are now deprecated as the preceding additions are more generic. However for backward compatibility they are preserved until inclusion of the library in Boost. Next follows the equivalences: timer<> ~ stopwatch<> process_timer ~ stopwatch<process_cpu_clock> run_timer ~ stopclock<> Bug Fixes * Try to correct warning C4251: 'boost::chrono::run_timer::m_format' : class 'std::basic_string<_Elem,_Traits,_Ax>' needs to have dll-interface to be used by clients of class 'boost::chrono::run_timer', by don't including inlines functions using the std::string m_format. For people that doesn't know it yet, Boost.Chrono library provides: * The C++0x Standard Library's common_type. * The C++0x Standard Library's compile-time rational arithmetic. * The C++0x Standard Library's time utilities, including: * Class template duration * Class template time_point * Clocks: * system_clock * monotonic_clock * high_resolution_clock * typeof registration for classes duration and time_point * Process clocks: * process_real_CPU_clocks, capturing real-CPU times. * process_user_CPU_clocks, capturing user-CPU times. * process_system_CPU_clocks, capturing system-CPU times. * process_cpu_clock, tuple-like class capturing at once real, user-CPU, and system-CPU times. * Stopwatches: * stopwatch, capturing elapsed Clock times. * stopwatch_accumulator, capturing cummulated elapsed Clock times. * scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * Stopclocks or Stopwatch reporters: * stopwatch_reporter, convenient reporting of models of Stopwatch results. * stopclock<Clock> shortcut of stopwatch_reporter<stopwatch<Clock>> Best regards, _____________________ Vicente Juan Botet Escribá

2 2

floating point FUD
by Thomas Klimpel 25 Jan '10

25 Jan '10

Hi, Find attached a small test program that tries to highlight some of the "usual" floating point traps. The essence is the following small function that outputs the results of some "buggy" floating point logic. The rest is just setting up the environment so that the bugs actually get triggered. void buggy_function(double eps = 1e-13, int length = 3, double delta = 1 / 7.0) { using namespace std; double alpha = 1e-13; double beta = eps; double a = length * delta; double b = length * delta; vector<double> inverse; for (int i = 0; i < length; ++i) inverse.push_back(1.0/(2*i+1)); vector<double> sorted; for (int i = 0; i < length; ++i) sorted.push_back(inverse[i]*delta); double t = -delta*sorted.size(); double tt = -sorted.size()*delta; bool t_tt = (abs(t-tt) < eps); bool abs_t = (abs(t) == -t); double c = (1-alpha) * a + alpha * b; double d = (1-beta) * a + beta * b; bool a_c = (a == c); bool b_d = (b == d); vector<bool> equal; for (int i = 0; i < length; ++i) equal.push_back(inverse[i]*delta == sorted[i]); std::cout << "t_tt = " << t_tt << "\nabs_t = " << abs_t << "\na_c = " << a_c << "\nb_d = " << b_d << "\n"; std::cout << "equal = ["; for (int i = 0; i < length; ++i) std::cout << " " << equal[i]; std::cout << " ]\n"; } The hypothetical "naive" programmer might expect the output: t_tt = 1 abs_t = 1 a_c = 1 b_d = 1 equal = [ 1 1 1 ] However, the actual output is not only different from this, but also depends on the compiler, the compiler settings, the current configuration of the floating points unit and the actual headers included directly or indirectly by the compilation unit. g++ test_fp.cpp -g -Wall compiles without warning and executes with output: t_tt = 0 abs_t = 1 a_c = 1 b_d = 1 equal = [ 1 1 1 ] g++ test_fp.cpp -DNDEBUG -O2 -msse2 -Wall compiles without warning and executes with output: t_tt = 0 abs_t = 1 a_c = 1 b_d = 1 equal = [ 1 0 0 ] I created a new project with MSVC9. The debug version compiles with warnings for the things that go badly wrong and executes with output: t_tt = 0 abs_t = 0 a_c = 1 b_d = 1 equal = [ 1 1 1 ] set floating point unit to 'high' precision: t_tt = 0 abs_t = 0 a_c = 1 b_d = 1 equal = [ 1 1 1 ] The release version compiles with warnings for the things that go badly wrong and executes with output: t_tt = 0 abs_t = 0 a_c = 1 b_d = 1 equal = [ 1 1 1 ] set floating point unit to 'high' precision: t_tt = 0 abs_t = 0 a_c = 0 b_d = 1 equal = [ 1 0 0 ] In my case (see the background story below), it was actually the trap represented by the output "abs_t = 0" instead of "abs_t = 1" that caught me on linux64 but worked on win32. (It turned out difficult to reproduce this with gcc, so the test program reproduces this trap with MSVC, even so MSVC warns quite explicitly about it). I think it is a funny exercise to debug the test program and find out what actually goes wrong (which is especially funny since most traps only go wrong with compiler optimization turned on). Regards, Thomas ------------------------ The background story: The recent reviews of [Constrained Value], [Polygon] and [GGL] all featured interesting disagreements over floating point issues: http://lists.boost.org/Archives/boost/2008/12/145655.php http://lists.boost.org/Archives/boost/2008/12/145788.php http://lists.boost.org/Archives/boost/2009/03/149567.php http://lists.boost.org/Archives/boost/2009/08/155767.php http://lists.boost.org/Archives/boost/2009/11/158560.php (These were long threads with many messages and many participants, so please don't misinterpret my choice of unrepresentative messages as any form of statement.) Last Wednesday, I had to give an internal live demo of a feature I just finished. I had done the development mostly on win32, but I wanted to run the demo on linux64, to be able to show examples of realistic size (full chip...). While preparing the presentation, I was surprised to find the accuracy of the results significantly worse than I remembered from my previous tests. I repeated my previous tests on linux64, and found out that there was indeed a problem with my code on linux64. I did the demo on win32, but was asked after the presentation to send the source code to somebody from another group. So I spent most of the night trying to find the problem in my code. When I found out that some code with floating point driven logic (I had written years ago) to analytically integrate radial symmetric functions over rectangular domains was showing unexpected behavior, I decided to postpone the floating point fights with the compiler to the next day. I told this story the next day in a group meeting, and was confronted with much floating point FUD and unrealistic suggestions, basically boiling down to either not writing floating point driven logic in the first place, or commenting it in excessive detail. So I lost my temper and explained that it was difficult enough for me to write this code with floating point driven logic, and that anybody suggesting writing it without floating point driven logic should do so please, because I'm unable to do it. I have to admit that I read "What Every Computer Scientist Should Know About Floating-Point Arithmetic" only superficially: http://www.engrng.pitt.edu/hunsaker/3097/floatingpoint.pdf http://docs.sun.com/source/806-3568/ncg_goldberg.html I also have to admit that I write code with floating point driven logic from time to time in case it seems unavoidable to me, and that this code often has bugs that are only discovered months after the code is already finished. But I never found a bug in such code that would have been a fundamental problem with floating point, but always just the "usual" floating point traps I keep overlooking by mistake. Now somebody will probably suggest that I should at least document the "usual" floating point traps then. So I created the attached small test program showing the "usual" floating point traps I could still remember having overlooked at least once. It was actually more difficult than expected to arrange the code in a way that the bugs are really triggered for typically compiler settings of MSVC and gcc.

9 16

[Quickbook] Integrating Spirit docs
by Hartmut Kaiser 24 Jan '10

24 Jan '10

Hey, Not exactly a question for the main devel list, but I'm not sure, where its best to send it to... What do I need to do in order to integrate the Spirit docs (generated by Quickbook) with Boosts overall doc page (i.e. http://www.boost.org/doc/libs/1_41_0/doc/html/libraries.html)? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

2 1

Re: [boost] RFC: Sequence Properties and Boost Algorithm/Functional
by Grant Erickson 24 Jan '10

24 Jan '10

On Fri, 22 Jan 2010 14:13:31 -0800 Jeffrey Hellrung <jhellrung(a)ucla.edu> wrote: On 1/23/10 12:35 AM, boost-request(a)lists.boost.org wrote: >> For a recent project, I needed to inquire about a sequence of objects and >> make a determination as to whether the sequences were: >> >> * Increasing >> * Strictly Increasing >> * Decreasing >> * Strictly Decreasing >> >> Looking through STL, Boost documentation, Boost sources and headers and the >> Boost mailing lists I was able to find neither an existing algorithm or >> stateful unary predicate functor for accomplishing this for a pair of input >> iterators. However, I was a bit surprised considering that this seems like a >> sequence property query that would tend to come up fairly often and serve a >> general utility. Did I just fail to form the proper search/query or am I >> overestimating the general utility? >> >> Is a smarter realization of this as an algorithm a potential candidate for >> boost::algorithm? > > Perhaps std::adjacent_find and std::less is all you need, e.g., to > determine if a sequence is decreasing? > > I.e., a sequence is decreasing iff all adjacent pairs of elements xi, > x[i+1] satisfies xi >= x[i+1] iff no adjacent pair of elements xi, > x[i+1] satisfies xi < x[i+1] (assuming that (!>=) == (<)). On Fri, 22 Jan 2010 15:24:32 -0800 Marshall Clow <mclow.lists(a)gmail.com> wrote: > I've got this floating around from a while back... > > [ examples omitted ] Marshall and Jeff: Thanks for the feedback. Marshall's feedback seems to indicate that, yes, there is likely general utility need for such functions and Jeff, you are correct that these algorithms are trivially composed from std::adjacent_find, std::not2 and std::{greater,less,greater_equal,less_equal}: namespace boost { namespace detail { template <typename ForwardIterator, typename BinaryPredicate> bool is_creasing(ForwardIterator first, ForwardIterator last, BinaryPredicate binary_pred) { return std::adjacent_find(first, last, std::not2(binary_pred)) == last; } } // namespace detail template <typename ForwardIterator> bool is_increasing(ForwardIterator first, ForwardIterator last) { typedef typename std::iterator_traits<ForwardIterator>:: value_type value_type; return detail::is_creasing(first, last, std::less_equal<value_type>()); } [ ... other three instances follow trivially ... ] } // namespace boost Unless there's any other feedback, I'll work on posting an implementation to Boost Vault. Regards, Grant

1 0

Re: [boost] MPL bitand.hpp and iso646.h on MSVC 2008
by Nelson, Erik - 2 24 Jan '10

24 Jan '10

After further research, I saw that this is a duplicate of very similar reports previously. I'm not sure if it's scheduled to be fixed, but it still seems to be a problem in boost v1.41 Thanks Erik

3 3

[lockfree::fifo] Review
by Andrew Venikov 24 Jan '10

24 Jan '10

I decided to start a new thread on this topic since the last thread on the same topic is pretty outdated and not everyone will see it. (you can disregard my reply to the previous thread as this one is more complete) First of all I think that having a library of lock-free algorithms/containers would be greatly beneficial to a great number of boost users. On the other hand, having implemented several lock-free algorithms, I know that it is notoriously hard to get them right. We'll need all the help we can get from knowledgeable people in the field. The implementation needs to be thoroughly reviewed. Let me give the first attempt at that. In this e-mail I'll be primarily concentrating on the algorithm correctness rather than the interface. First, let me start with the choice of the algorithm for the fifo queues: Magued Michael and Michael Scott's "Simple, Fast, and Practical Non-blocking and blocking concurrent queues". I really think it is the best choice. Having said that, however, I need to point out that there some inherent limitation in this algorithm. The first limitation is that you can't peek at the head of the queue without dequeueing the element first, hence you can't get an interface that is conformant with std::queue. But I truly believe that it will be the case with any lock-free queue implementation, hence we should abandon the hope of having a lock-free queue look the same as std::queue Second, this algorithm makes certain assumptions about the ability to access memory that has been freed. The algorithm can try to read memory that has been de-allocated. (See further down for description of how). Several debug implementations of malloc/free store every allocated element on one page and when the element is freed, the page is marked protected for both reading and writing. That means that this algorithm can only work with a subset of custom allocators. Your "free_list" for example can't work with it since it's possible for a node to be freed when you call "deallocate". The "caching_freelist" and "static_freelist" on the other hand work just fine because they never return the memory back to the system. Third, and the biggest limitation, is the algorithm's assumption that you can store a pointer to an element plus an ABA tag in a contiguous memory space that can be passed to a CAS instruction. I believe not all platforms provide a DCAS instruction, that's why you're trying to work around this issue by using "packed pointers", i.e. storing the ABA tag in the part of the pointer that presumably is never used. The problem with that, however, is that some libc implementations of malloc/free do use all the bits in the pointer for their own needs, so you can't assume that you can meddle with them. My experience with this algorithm shows that the safest approach is to use a pre-allocated array for the queue and replace pointers with indexes into the array. Assuming that the size of an index is sufficiently lower than the size of a pointer, you can use the remaining bits to store the ABA tag. This alleviates both point 2 and 3. This does mean however, that the queue can't have an unbound size, the size has to be specified during the queue instantiation. Fourth, on platforms where CAS is implemented using LL/SC (such as PowerPC and MIPS), it is possible to livelock. The problem with LL/SC on most platforms is that the write granulum for marking LL's address as "dirty" isn't just the memory pointed to by LL, but the whole cache line where the memory resides. On these platforms it is important to make sure that each "node" of the queue is located on a separate cache line. Here's the code of your enqueue: bool enqueue(T const & t) { node * n = alloc_node(t); if (n == NULL) return false; for (;;) { atomic_node_ptr tail (tail_); //1 read_memory_barrier(); //2 atomic_node_ptr next (tail->next); //3 if (likely(tail == tail_)) //4 { if (next.get_ptr() == 0) //5 { if ( tail->next.cas(next, n) )//6 { tail_.cas(tail, n); return true; } } else tail_.cas(tail, next.get_ptr()); } } } 1. You're missing write barrier after a call to alloc_node(). Rational: alloc_node sets the "next" pointer of the newly allocated node to NULL. That is a store to shared memory. Setting next pointer to NULL has to be observable to other threads BEFORE they observe the inserted node. If you don't insert a write barrier, it is possible for other threads to see the new element in the list before element's next pointer is initialized with NULL. 2. You've misplaced the read_barrier. Rational: Line 4 checks the validity of the load done on line 3. That means that the read_barrier should be between lines 3 and 4. If you don't have a read_barrier after loading *tail->next, then this load can happen after the load of tail_ on line 4, which defies the purpose of line 4. Here's a scenario that makes it clear: State: queue is well-formed and tail_ points to the last element. 1. Thread A executes line1. State: the queue is unchanged and Thread A has a local copy of tail_ 2. Since there's no read barrier after line 3, loads at lines 3 and 4 happen out-of-order. tail_ is pre-loaded for comparison at line 4. 3. Thread B removes the element pointed by tail_, advances tail_ further State: tail_ is advanced, the old element is removed and given back to the allocator. A's local copy of tail_ becomes stale. 4. Thread A executes line 3 State: A's copy of tail is stale. This copy is used to load memory that has been reclamed by the allocator and possibly modified. The value of the memory happens to be 0. 5. Thread A executes line 4. Since tail_ has been preloaded, line 4 succedes. 6. Line 5 succedes 7. Line 6 succedes. Boom: you've just modified a piece of memory not controlled by the queue. You still need to have a barrier between lines 1 and 3, but here only a data dependency barrier will suffice, which is a weaker form of a read barrier and on most all platforms is a no-op since data dependent loads can be handled by processors automatically. 3. Your tail_ and head_ should be volatile. Furthermore, the getters for you tagged_ptr (like get_ptr, operator->() and operator* ) should return pointers/references to volatile types. Rational: If your tail_ is not volatile, then the compiler is free to load head_ just once and line 4 effectively becomes a no-op. Here's code for your "dequeue": bool dequeue (T * ret) { for (;;) { atomic_node_ptr head (head_); //1 read_memory_barrier(); //2 atomic_node_ptr tail(tail_); //3 node * next = head->next.get_ptr(); //4 if (likely(head == head_)) //5 { if (head.get_ptr() == tail.get_ptr()) //6 { if (next == 0) return false; tail_.cas(tail, next); } else { *ret = next->data; //7 if (head_.cas(head, next)) //8 { dealloc_node(head.get_ptr()); //9 return true; } } } } } 1. Again, you need to put read_barrier between lines 4 and 5. Only data dependency barrier will suffice at line 2. 2. You need to add write barrier after line 7 for the same reason as in the enqueue. Hope this was descriptive, Andy Venikov.

10 64

[1.42.0] Beta 1 available on Sourceforge
by Beman Dawes 23 Jan '10

23 Jan '10

1.42.0 beta 1 is now available. This release contains one new library and numerous bug fixes for existing libraries. For details, including download links, see http://beta.boost.org/users/news/version_1_42_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ There are a few known problems in the beta: * An odd 'simplesectsep' tag that doxygen creates which has turned up in the generated documentation, such as at http://tinyurl.com/ygbgkge. * Doxygen isn't expanding some of the macros in Boost.Accumulators. * A nasty bug in Spirit affecting copy construction of rules (rev. 50156) has been tracked down and fixed, but the fix was too late for the beta. These will be fixed in the final release. Please report any other problems by responding to this message on either the users or the main developers mailing lists. Thanks, --The Boost release team

3 3

help detecting presence of operator[]
by Jeffrey Hellrung 23 Jan '10

23 Jan '10

Hi all, I'm trying to perform a compile-time check to determine if a class has an operator[]. I'm using a "trick" I think I've seen in Adobe's library and on this list in the past: -------- BEGIN CODE -------- template< class T > struct has_op_bracket { struct base_t { void operator[]( int ); }; struct derived_t : T, base_t { }; template< void (base_t::*)( int ) > struct sfinae { typedef char type; }; template< class U > static typename sfinae< &U::operator[] >::type is_ambiguous(int); template< class U > static int is_ambiguous(...); static const bool value = sizeof( is_ambiguous< derived_t >(0) ) != 1; }; -------- END CODE -------- The way I understand this working is if T has no operator[], then &derived_t::operator[] unambiguously refers to *base_t::operator[], and so the first is_ambiguous overload is selected. Otherwise, &derived_t::operator[] is ambiguous, which is sufficient (I guess...?) for SFINAE to kick in, and the second is_ambiguous overload is selected. Now given the following definitions of X0 and X1: -------- BEGIN CODE -------- struct X0 { }; struct X1 { void operator[](void*); }; -------- END CODE -------- then the following static assertions pass, as expected: -------- BEGIN CODE -------- BOOST_STATIC_ASSERT(( !has_op_bracket<X0>::value )); BOOST_STATIC_ASSERT(( has_op_bracket<X1>::value )); -------- END CODE -------- However, if X2 is defined as -------- BEGIN CODE -------- struct X2 { template< class T > struct R : T { }; template< class T > typename R<T>::type operator[](T); }; -------- END CODE -------- then has_op_bracket<X2>::value fails to compile on MSVC9, but (according to Dinkum Exam[1]) it does compile just fine on "EDG/C++". The error in MSVC9 is -------- BEGIN OUTPUT -------- error C2516: 'T' : is not a legal base class 1> d:\test\main.cpp(9) : see declaration of 'T' 1> d:\test\main.cpp(9) : see reference to class template instantiation 'X2::R<T>' being compiled 1> with 1> [ 1> T=int 1> ] 1> d:\test\main.cpp(21) : see reference to class template instantiation 'has_op_bracket<T>' being compiled 1> with 1> [ 1> T=X2 1> ] -------- END OUTPUT -------- generated by the following program: -------- BEGIN CODE -------- template< class T > struct has_op_bracket { struct base_t { void operator[]( int ) const; }; struct derived_t : T, base_t { }; template< void (base_t::*)( int ) const > struct sfinae { typedef char type; }; template< class U > static typename sfinae< &U::operator[] >::type is_ambiguous(int); template< class U > static int is_ambiguous(...); static const bool value = sizeof( is_ambiguous< derived_t >(0) ) != 1; // line 9 }; struct X2 { template< class T > struct R : T { }; template< class T > typename R<T>::type operator[](T); }; int main() { has_op_bracket<X2>::value; // line 21 return 0; } -------- END CODE -------- What I don't understand is why MSVC is trying to instantiate R<int>. It seems to be grabbing the int from the parameter type of the member function pointer template parameter in sfinae, which doesn't seem like the right thing to do. I can change that parameter to anything else (as long as it doesn't have a nested type typedef) and the error persists. Is MSVC correct, or is this a compiler bug? Either way, is there an alternative, more portable approach to achieve the desired effect? Thanks in advance, - Jeff [1] http://www.dinkumware.com/exam/default.aspx

2 3

[test] mock objects
by Michael Robinson 23 Jan '10

23 Jan '10

Hi, I am a boost unit test newbie. I have been looking at the documentation and examples and would like to know if there is any documentation that specifically addresses the use of mock objects: I am specifically interested in how to interpret the output of est_example1.cpp and est_example2.cpp; as well as learning what the required format of the expectations log file (.elog) to be used for logged_exp_example.cpp is. Thank you, Mike ____________________________________________________________ Nutrition Improve your career health. Click now to study nutrition! http://thirdpartyoffers.netzero.net/TGL2241/c?cp=U1sp_d8XptT4jkLd7e_KlAAAJ1…

2 2

[typeof] Variadic functions
by Sergey Zubkovsky 22 Jan '10

22 Jan '10

Hi, Here is a patch to support variadic functions in the Boost.Typeof. Can anyone check it and commit? Thank you. Index: register_functions.hpp =================================================================== --- register_functions.hpp (revision 57837) +++ register_functions.hpp (working copy) @@ -18,18 +18,25 @@ #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() #ifndef BOOST_TYPEOF_LIMIT_FUNCTION_ARITY -#define BOOST_TYPEOF_LIMIT_FUNCTION_ARITY 10 +#define BOOST_TYPEOF_LIMIT_FUNCTION_ARITY 15 #endif enum { FUN_ID = BOOST_TYPEOF_UNIQUE_ID(), - FUN_PTR_ID = FUN_ID + 1 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - FUN_REF_ID = FUN_ID + 2 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - MEM_FUN_ID = FUN_ID + 3 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - CONST_MEM_FUN_ID = FUN_ID + 4 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - VOLATILE_MEM_FUN_ID = FUN_ID + 5 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), - VOLATILE_CONST_MEM_FUN_ID = FUN_ID + 6 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY) + FUN_VAR_ID = FUN_ID + 1 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_PTR_ID = FUN_ID + 2 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_VAR_PTR_ID = FUN_ID + 3 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_REF_ID = FUN_ID + 4 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + FUN_VAR_REF_ID = FUN_ID + 5 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + MEM_FUN_ID = FUN_ID + 6 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + MEM_FUN_VAR_ID = FUN_ID + 7 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + CONST_MEM_FUN_ID = FUN_ID + 8 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + CONST_MEM_FUN_VAR_ID = FUN_ID + 9 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_MEM_FUN_ID = FUN_ID + 10 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_MEM_FUN_VAR_ID = FUN_ID + 11 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_CONST_MEM_FUN_ID = FUN_ID + 12 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY), + VOLATILE_CONST_MEM_FUN_VAR_ID = FUN_ID + 13 * BOOST_PP_INC(BOOST_TYPEOF_LIMIT_FUNCTION_ARITY) }; BOOST_TYPEOF_BEGIN_ENCODE_NS Index: register_functions_iterate.hpp =================================================================== --- register_functions_iterate.hpp (revision 57837) +++ register_functions_iterate.hpp (working copy) @@ -6,6 +6,12 @@ #define n BOOST_PP_ITERATION() +#if ( n > 1 ) +# define comma , +#else +# define comma +#endif + // function pointers template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> @@ -15,6 +21,13 @@ typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_PTR_ID + n) type; }; +template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> +struct encode_type_impl<V, R(*)(BOOST_PP_ENUM_PARAMS(n, P)comma ...)> +{ + typedef R BOOST_PP_CAT(P, n); + typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_VAR_PTR_ID + n) type; +}; + template<class Iter> struct decode_type_impl<boost::mpl::size_t<FUN_PTR_ID + n>, Iter> { @@ -24,6 +37,15 @@ typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; }; +template<class Iter> +struct decode_type_impl<boost::mpl::size_t<FUN_VAR_PTR_ID + n>, Iter> +{ + typedef Iter iter0; + BOOST_TYPEOF_DECODE_PARAMS(BOOST_PP_INC(n)) + typedef BOOST_PP_CAT(p, n)(*type)(BOOST_PP_ENUM_PARAMS(n, p)comma ...); + typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; +}; + #ifndef BOOST_TYPEOF_NO_FUNCTION_TYPES // function references @@ -35,6 +57,13 @@ typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_REF_ID + n) type; }; + template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> + struct encode_type_impl<V, R(&)(BOOST_PP_ENUM_PARAMS(n, P)comma ...)> + { + typedef R BOOST_PP_CAT(P, n); + typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_VAR_REF_ID + n) type; + }; + template<class Iter> struct decode_type_impl<boost::mpl::size_t<FUN_REF_ID + n>, Iter> { @@ -53,6 +82,13 @@ typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_ID + n) type; }; + template<class V, class R BOOST_PP_ENUM_TRAILING_PARAMS(n, class P)> + struct encode_type_impl<V, R(BOOST_PP_ENUM_PARAMS(n, P)comma ...)> + { + typedef R BOOST_PP_CAT(P, n); + typedef BOOST_TYPEOF_ENCODE_PARAMS(BOOST_PP_INC(n), FUN_VAR_ID + n) type; + }; + template<class Iter> struct decode_type_impl<boost::mpl::size_t<FUN_ID + n>, Iter> { @@ -62,6 +98,15 @@ typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; }; + template<class Iter> + struct decode_type_impl<boost::mpl::size_t<FUN_VAR_ID + n>, Iter> + { + typedef Iter iter0; + BOOST_TYPEOF_DECODE_PARAMS(BOOST_PP_INC(n)) + typedef BOOST_PP_CAT(p, n)(type)(BOOST_PP_ENUM_PARAMS(n, p)comma ...); + typedef BOOST_PP_CAT(iter, BOOST_PP_INC(n)) iter; + }; + #endif//BOOST_TYPEOF_NO_FUNCTION_TYPES #ifndef BOOST_TYPEOF_NO_MEMBER_FUNCTION_TYPES @@ -83,5 +128,6 @@ #define BOOST_TYPEOF_id VOLATILE_CONST_MEM_FUN_ID #include <boost/typeof/register_mem_functions.hpp> +#undef comma #undef n #endif

2 3

[iostreams 1.42 beta1] gcc warning
by Christoph Duelli 22 Jan '10

22 Jan '10

boost/iostreams/detail/config/unreachable_return.hpp:25:7: warning: no newline at end of file would be great it that could be fixed. Best regards Christoph

1 0

[Polygon] Template error in CodeWarrior when attempting union on polygon_set_data
by Kef Schecter 22 Jan '10

22 Jan '10

I hesitate to mark this as [Polygon] because the error message is in a different part of Boost. However, I have little idea what the actual cause of the problem is or what any of the relevant stuff even means, so I figure [Polygon] is as good as anything at the moment... As before, this is a custom version of CodeWarrior an embedded ARM system, so I have no idea how well it corresponds with other versions of CodeWarrior. Here is a trivial program that illustrates the problem, using the BOOST_VERY_LITTLE_SFINAE patch from the last discussion here: #include <iostream> #define BOOST_VERY_LITTLE_SFINAE #include <boost/polygon/polygon.hpp> using namespace boost::polygon; using namespace boost::polygon::operators; int main() { polygon_set_data<int> ps; ps += rectangle_data<int>(0, 0, 1, 1); return 0; } This results in the following error message : Error : illegal use of template argument dependent type 'T::type' The error occurs in this part of boost/mpl/aux_/preprocessed/plain/and.hpp: template< typename T1, typename T2, typename T3, typename T4 > struct and_impl< true,T1,T2,T3,T4 > : and_impl< BOOST_MPL_AUX_NESTED_TYPE_WKND(T1)::value , T2, T3, T4 , true_ > { }; Any ideas about what's wrong or how to fix it? - Kef

2 3

Re: [boost] boost::mpl::for_each and value_initialized
by Niels Dekker - address until 2010-10-10 22 Jan '10

22 Jan '10

>> Do I understand correctly that you want the memset call to be >> skipped for those compiler versions that have implemented >> value-initialization entirely correctly? Peter Foelsche wrote: > I'm only concerned with boost::mpl::for_each > This function calls a function object by passing an object of the > matching type. > The contents of this object usually do not matter -- and in case they > do, the programmer can write a default constructor to initialize this > object. So there is no need in boost::mpl::for_each to call > value_initialized. So you think the issue can be resolved properly, merely by modifying mpl/for_each.hpp, right? You proposed at http://lists.boost.org/Archives/boost/2009/09/155805.php to modify mpl/for_each.hpp by changing: ! value_initialized<arg> x; ! aux::unwrap(f, 0)(boost::get(x)); Into: ! aux::unwrap(f, 0)(arg()); I see some subtle differences here. First of all, boost::get(x) return a reference to an lvalue, while arg() is an rvalue. Do you think that's okay? Secondly, things *might* go wrong if arg doesn't have a user-declared default-constructor *and* the compiler hasn't correctly implemented value-initialization. That's why Fernando and I added the memset call to boost::value_initialized, of course. But you think the data members of the temporary arg() won't be accessed anyway, right? Unless arg has a user-declared default-constructor? I'm sorry I don't know mpl/for_each.hpp well enough. But if the answer to each of the above questions is yes, I guess your proposal is fine. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

2 1

MPL bitand.hpp and iso646.h on MSVC 2008
by Nelson, Erik - 2 21 Jan '10

21 Jan '10

If I make a program like #undef BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #include <iso646.h> #include <boost/mpl/bitand.hpp> I get an error like boost/mpl/aux_/include_preprocessed.hpp(37) : fatal error C1083: Cannot open include file: 'boost/mpl/aux_/preprocessed/plain/&.hpp': No such file or directory And if I change it to #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #include <iso646.h> #include <boost/mpl/bitand.hpp> I get 1>c:\work\boost\boost/mpl/aux_/numeric_op.hpp(86) : error C2332: 'struct' : missing tag name 1>c:\work\boost\boost/mpl/aux_/numeric_op.hpp(86) : error C3306: 'boost::mpl::<unnamed-tag>': unnamed class template is not allowed 1>c:\work\boost\boost/mpl/aux_/numeric_op.hpp(86) : error C2143: syntax error : missing ';' before '&' I think the problem is in boost/mpl/bitand.hpp, where #define AUX778076_OP_PREFIX bitand Is defined. 'bitand' is (nonconformantly) #defined to '&' in VC 2008's iso646.h, borking the definition of AUX778076_OP_PREFIX. The fix seems to be to #define AUX778076_OP_PREFIX to something else that MSVC doesn't stomp on. Thanks Erik

1 0

Any Chances for Boost Stable?
by Artyom 21 Jan '10

21 Jan '10

Hello, This mail is rather discussion of possible future Boost policy rather then concrete features it provides. Is there any chance for Stable Boost version? --------------------------------------------- What do I mean stable? Stable as Qt4, stable as STL Port, or STL. Boost is one of the greatest platforms for development of bleeding edge technologies. Like Boost.Asio is one of the greatest Asynchronous API libraries. On the other hand, this library is extremely unstable: each release breaks compatibility with previous one! When I compile a program or library that uses STL I expect that it would continue to work as long as compiler keeps table ABI (GCC - for years). I can compile great GUI application with Qt and expect from it to work for years and be sure that core Qt library includes updates, bug fixes and so. I can't do it with Boost! -------------------------------------------------------- Is there any chance to create a stable Boost branch that includes: - All libraries included in Tr1 - Various other stable libraries. This branch would keep: stable API and ABI, It may include additional libraries and features as long as they do not break API/ABI. Adopt the code such that different changes would not break ABI. For example, if shared_ptr on specific platform uses mutex or atomic counter, it would not be changed withing release because of new supported feature -- meaning config.hpp should be recompiled similarly as it done with autotools. Adopt pimpl policies of Qt to make sure that classes can be easily extended without breaking them. ------------------------------------ I know that this is lot of work and this is totally different from current Boost policy. But Boost should not be only experimental library... It should be as stable as STLPort or STL. -------------------------------- Do we need Boost.Stable branch? -------------------------------- Artyom

9 9

Boost is complicated. This forum too. (please help about accumulators)
by Mahdavi 21 Jan '10

21 Jan '10

{I beg your pardon if you receive multiple of this. I am not sure about its receive.} I hope I am in a right place. I heard that boost is this and that. I am new to boost but have 10 years of programming experience with c++. It is about 10 hours I am searching for a sample about how can I reach to a histogram. For clarity. Please (please I beg you) write some few line of code how to get a histogram. double s[] = { 0, .5 , .6 , .65 , .45 , .7 , .6 , .65 , .45 , .7 , .59 , .52 } ; I want histogram of s ?? I tried many boost codes but I failed all the time. Please help. -- View this message in context: http://old.nabble.com/Boost-is-complicated.-This-forum-too.-%28please-help-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[GGL] Can't seem to use equals on multi_polygons
by Kef Schecter 21 Jan '10

21 Jan '10

When I try to use equals() on multi_polygons, the compiler blows up, giving a template error. I've tried this in CodeWarrior and MSVC. Using equals() on two polygon_2d's works fine, but it doesn't like it when I use multi_polygons. Is equals() for multi_polygons not implemented, or am I just missing something? I've attached a test program that demonstrates the problem. (I've defined my own integer-based types, like polygon_2di, because I need this to work on an embedded platform with no FPU. Using polygon_2d and doubles instead shows the same problem, though.) - Kef

2 6

error LNK2005
by Kevin Li 21 Jan '10

21 Jan '10

Hello, when the run boost test cases (Version 1.41.0), I got quite a few LNK2005 errors. Below is an example when run a Data_Time test: msvcprt.lib(MSVCP80.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z) already defined in dates_as_strings.obj msvcprt.lib(MSVCP80.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)" (??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in dates_as_strings.obj It seems to me that there is a conflict between system library and the Boost library, but I am not sure if this is a bug or the Boost library is not correctly built. Any clue would be very appreciated. Best regards, --Kevin _________________________________________________________________

3 5

library for differentiation (interest research)
by DE 21 Jan '10

21 Jan '10

hi all recently i have interested in evaluating of derivatives of complicated functions and discovred that there is a finely developed technique which is called algorithmic differentiation (visit www.autodiff.org if you are interested) the resulting code using an imagined lib may look like this struct { template<typename type> type operator()(type x) //defining function { return sin(x); } } foo; //... double x = 42., f = foo(x), //evaluating function value df = deriv(foo, x); //evaluating derivative value notice that the function' code is untouched the very amazing thing is that the function may be arbitrarily complex it can even be a matrix inversion or eigenvalues evaluation so we get e.g. derivatives of eigenvalues with respect to system parameters gradients, jacobians and higher order derivatives are also possible there are numerous libraries implementing this technique and the questions are: - does it fit into boost collection of libraries? - is it worth building a distinct boost (well-designed) library or adopt a specific lib or to use other (non-boost) libs? and the like personally i am going to investigate the so called tangent mode (or direct mode which is very simple) and probably implement it if i don't find any suitable implementation for my own purposes -- Pavel

2 1

shared_ptr/intrusive_ptr conflict
by Gennadiy Rozental 21 Jan '10

21 Jan '10

Hi, Following snippet fails to compile with gcc 4: ---------------- #include <boost/shared_ptr.hpp> #include <boost/intrusive_ptr.hpp> boost::shared_ptr<void> sharedPtr; template <class T> boost::shared_ptr<T> get_concrete() { return boost::static_pointer_cast<T,void>(sharedPtr); } int main() { boost::shared_ptr<int> p = get_concrete<int>(); } ---------------- due to the presence of intrusive_ptr.hpp. it seems like SFINAE should have kicked in. Any help with how to work this around? Do we need to fix above header? Gennadiy.

2 2

[String Algo] error in ireplace_first or ireplace_all with std::wstring under gcc 3.4.2 (MingW)
by Doug Swanson 20 Jan '10

20 Jan '10

I apologize in advance if this is an inappropriate place to post this question. I posted it to the boost-users list half a week ago and got no replies, so I am trying here instead. The following code compiles and runs without error under g++ in Windows, GCC 3.4.2 (MingW): <code> #include <cstdio> #include <string> #include <boost/algorithm/string.hpp> using namespace std; using namespace boost; int main( void ) { string test = "This is a test"; ireplace_first( test, "test", "success" ); printf( "%s\r\n", test.c_str() ); return 0; } </code> The output is correct: "This is a success". If I change the above code to use a std::wstring instead, it will compile, but it will crash on execution: <code> #include <cstdio> #include <string> #include <boost/algorithm/string.hpp> using namespace std; using namespace boost; int main( void ) { wstring test = L"This is a test"; ireplace_first( test, L"test", L"success" ); printf( "%ws\r\n", test.c_str() ); return 0; } </code> Setting a breakpoint on std::terminate() in gdb gives the following backtrace: Breakpoint 1, 0x00407ae6 in std::terminate() () (gdb) bt #0 0x00407ae6 in std::terminate() () #1 0x00404dc2 in __cxa_throw () #2 0x004021d2 in std::__throw_bad_cast() () #3 0x00434c69 in std::ctype<wchar_t> const& std::use_facet<std::ctype<wchar_t> >(std::locale const&) (__loc=@0x22fe8c) at C:/Applications/Dev-Cpp//bin//../lib/gcc/mingw32//3.4.2//..//..//../../include/c++/3.4.2/bits/locale_facets.tcc:112 #4 0x0043415c in wchar_t std::toupper<wchar_t>(wchar_t, std::locale const&) ( __c=84, __loc=@0x22fe8c) at C:/Applications/Dev-Cpp//bin//../lib/gcc/mingw32//3.4.2//..//..//../../include/c++/3.4.2/bits/locale_facets.h:4553 #5 0x0041648c in bool boost::algorithm::is_iequal::operator()<wchar_t, wchar_t> (wchar_t const&, wchar_t const&) const (this=0x22fe8c, Arg1=@0x3e3df4, Arg2=@0x43702e) at C:/Applications/Boost_new/boost/algorithm/string/compare.hpp:71 #6 0x004163fb in boost::iterator_range<__gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > > boost::algorithm::detail::first_finderF<wchar_t const*, boost::algorithm::is_iequal>::operator()<__gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > >(__gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, __gnu_cxx::__normal_iterator<wchar_t*, std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >) const (this=0x22fe80, Begin={_M_current = 0x3e3df4}, End={_M_current = 0x3e3e10}) at C:/Applications/Boost_new/boost/algorithm/string/detail/finder.hpp:76 #7 0x00413fe8 in void boost::algorithm::find_format<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::algorithm::detail::first_finderF<wchar_t const*, boost::algorithm::is_iequal>, boost::algorithm::detail::const_formatF<boost::iterator_range<wchar_t const*> > >(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&, boost::algorithm::detail::first_finderF<wchar_t const*, boost::algorithm::is_iequal>, boost::algorithm::detail::const_formatF<boost::iterator_range<wchar_t const*> >) ( Input=@0x22ff50, Finder=@0x22fe80, Formatter={m_Format = {m_Begin = 0x43701e, m_End = 0x43702e, singular = false}}) at C:/Applications/Boost_new/boost/algorithm/string/find_format.hpp:146 #8 0x004141b5 in void boost::algorithm::ireplace_first<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, wchar_t[5], wchar_t[8]> (std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&, wchar_t[5] const&, wchar_t[8] const&, std::locale const&) (Input=@0x22ff50, Search=@0x43702e, Format=@0x43701e, Loc=@0x22ff40) at C:/Applications/Boost_new/boost/algorithm/string/replace.hpp:259 #9 0x004014e8 in main () at test.cpp:11 I am not competent enough with Boost to understand what the call stack is telling me, except that __throw_bad_cast( ) is the source of the crash. ireplace_all gives the same behavior as ireplace_first above. Furthermore, the problem does not arise if I use replace_first or replace_all instead of ireplace_first or ireplace_all. It compiles and runs correctly. Finally, the problem does not arise if I compile using MSVC 2008. It compiles and runs correctly. Does this indicate a problem with gcc (MingW) unicode support? Is there an easy way to circumvent it? Thank you very much for any suggestions!

3 6

[gil] native image format loaders/savers
by Domagoj Saric 20 Jan '10

20 Jan '10

Would a contribution to GIL in the form of alternate 'native' (e.g. using GDI+ on Windows) implementations (to remove the libjpeg, libtiff, libpng and zlib requirements) of image format parsers be accepted? -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

2 3

[Boost.tracer] library request
by Andrew Chinkoff 20 Jan '10

20 Jan '10

[Boost.tracer] library request is founded on a desire to trace some statistics about program execution. The sample program below demonstrates these statistics. Sample program file: ******** START OF FILE ******** #include <tracer.h> void foo() { TRACE_LIFETIME; usleep(rand() % 100000); } int main() { TRACE_LIFETIME; for(int i = 0; i < 100; ++i) foo(); } ******** END OF FILE ******** Produced log file: ******** START OF FILE ******** All the program time: 05265686 us (micro secs) TRACE POINT: Function: int main() Calls: 0000000001 times Average T between calls: 0000000000 us Average life T: 0005264459 us File: main.cpp Line: 00000009 TRACE POINT: Function: void foo() Calls: 0000000100 times Average T between calls: 0000051665 us Average life T: 0000052606 us File: main.cpp Line: 00000004 ******** END OF FILE ******** Comment: TRACE_LIFETIME is a MACRO that traces some scope statistics, namely: "Function" - the function name where the scope is; "Calls" - number of entries into this scope; "Average T between calls" - average time period between "Calls"; "Average life T" - average time spent in this scope. Conclusion: I think it is reasonable to introduce this trace functionality into (for example) boost::tracer namespace. I had wrote tracer.h and tracer.cpp source files and I wish Boost community to consider them. Thank You.

4 6

[1.42.0] Beta 1 release candidate
by Beman Dawes 20 Jan '10

20 Jan '10

Release candidates for 1.42.0 beta 1 are available at http://boost.cowic.de/rc/ Please download, do a build, and report results here. Also let us know if you spot any problems or have any other comments. Thanks, --Beman

7 8

[date_time] [patch][1.42] Trac #2757 - fix warning
by Sylvester-Bradley, Gareth 20 Jan '10

20 Jan '10

On 19 January 2010 22:14, Marshall Clow wrote: > Downloaded, built w/no errors (a bunch of warnings) here. > Mac OS X 10.6.2, gcc 4.2.1 I guess it's too late to apply the simple patch for date_time from ticket #2757 in 1.42.0, but how about on trunk? This would suppress over 1000 instances of the same warning when compiling my app at /W4 on Windows, VC90; this is the only warning I see! https://svn.boost.org/trac/boost/ticket/2757 The ticket was opened almost a year ago, and FWIW the patch (included at that time) has worked for more than one person. Best regards, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

1 0

[BoostCon 2010] Final Call for Participation
by Hartmut Kaiser 20 Jan '10

20 Jan '10

Please distribute! -------------------------------- 4th Annual Boost Conference 2010 -------------------------------- Aspen CO, USA, May 10-14, 2010, www.boostcon.com Final Call for Participation -------------------------------- Important dates: Proposal submissions Extended to January 3, 2010 Proposals decisions sent January 25, 2010 (tentative program available) Fully scheduled program available February 10, 2010 Session materials due April 15, 2010 -------------------------------- We invite you to submit session proposals to the 4th Annual Boost Conference: BoostCon 2010 (Aspen CO, USA, May 10-14, 2010). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2010 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at two constituencies: Boost end-users and hard-core Boost library and tool developers. The program fosters interaction and engagement within and across those two groups, with an emphasis on hands-on, participatory sessions. Session topics -------------- Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it will change life for users and library writers * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops Workshops provide an active arena for advancements in Boost- relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). Submission details ------------------ All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon10. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon website and will be available to attendees. For general information on the BoostCon 2010 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon10(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

2 1

Re: [boost] Boost library submission (poll for interest)
by Bob Walters 20 Jan '10

20 Jan '10

Sorry for the delay here. Original reply bounced due to 'reply to digest' subject line. On Tue, 5 Jan 2010 21:21:29 +0100, "vicente.botet" <vicente.botet(a)wanadoo.fr> wrote: > I'm interested on a library that has transactional shared memory, but something more general that your containers database in shared memory. Can your library be extendeed to manage with types that are not containers? Currently there is an interface between the trans infrastructure (TI) and the containers allowing the containers to offer transactional operations, and indicate to the TI how they should be logged, committed, etc. This was intended to help make adding containers easier. There isn't really an assumption that transactional objects are containers - they could be anything which adheres to the interface. For example: I'm planning a quick wrapper for types T which makes T transactional for updates done to it via operator=. I need this for integerss that I want to use as sequences in one use of STLdb. (e.g. for key generation.) > If I have understood, the data is stored using Boost.Interprocess. Could you clarify why do you force the stored types to be Serializable? I'm not relying on the durability of the boost interprocess region. Nor am I trying to serialize the shared memory from directly to disk. Stefan has challenged me to do that, and I'm considering a variation which would do that, but it isn't without it's own issues. For now, I went with the approach of using serialization for sending K,V types to logs or checkpoints as a way to avoid those issues. My current concern with direct storage is that (assuming K and V may not be concrete types) it seems like it will require a lot of memory use tracking which could add an unwanted expense to shared memory pointer traversal. > With your library, there are alreasy 3 libraries under construction providing a transactional service (Boost.STLdb, Boost.Persistent and TBoost.STM). The ideal would be to have a single transactional framework with several transactional resources, e.g shared memory resource (Boost.STLdb), persistent resource (Boost.Persistent ), in memory resource (Boost.STM). If I'm not wrong Boost.Persistent contains already a Ressource concept. I would like to see how this transactional framework can be made generic so the three libraries can share the same transaction. Stefan, Bob, are you interesteed in participating on such a framework? Yes. Stefan had suggested this in private e-mails earlier, and I'll have to adapt to fit his interfaces. As I've alluded previously, I would like to see it possible to use Boost.Persistence with my library, as several shortcomings of STLdb would be addressed in that way. Part of doing that involved bringing all transaction control under one manager. Stefans library is the most robust in this sense, so I plan to work with and adapt to his interfaces. > Could you give a link from where to download the code. If you want I can add your library to the Boost Libraries Under Construction page https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction. Currently it's in subversion only on sourceforge. I'm finishing some changes to the checkpointing mechanism, and I'm going to finish that first. Will let you know when its ready, thereby supporting the under construction entry. If it helps at all, I could move the SVN repository to the sandbox, or post the tarball into the Vault (?)

5 12

[boost-lists][string algo] C++0x string algo.
by Germán Diago 19 Jan '10

19 Jan '10

Hello. I'm using c++0x-enabled c++0x compiler. I was going to use this piece of code: typedef vector< string > split_vector_type; split_vector_type svec; split(svec, str, is_any_of(":")); for c++0x, I shouldn't need to define a typedef to take advantage of that. I think it would be more idiomatic (and way easier to do) to use something like this: auto splitrange = split(str, is_any_of(":")); So I would like to know if it's possible to map split to a range result by default (not a vector, maybe). And it could also be used with a vector if you put it explicitly: auto splitvec = split<vector<string>>(str, ....); I think the whole library should be readapted to return by value. I've spent some time figuring how to use the library because of the out parameters in the arguments. Can anyone tell me if there is any plan to change this? Or if it should be possible? Thanks in advance.

5 11

[random] normal_distribution
by Neal Becker 19 Jan '10

19 Jan '10

According to: http://www.taygeta.com/random/gaussian.html The method we're using is less stable and less computationally efficient than the method presented there. Is this true?

1 0

The boost component dependencies blues
by Stefan Seefeld 19 Jan '10

19 Jan '10

I'm not sure what the best place is for this question, but since it is symptomatic for a general theme (which I have complained about a lot in the past), I'll write it here: I'm trying to generate a boost subset that allows me to build boost.python and its dependencies into my own package. To do that, I ran "bcp python ...". I'm surprised to find all these components in the generated source tree: date_time, graph, mpi, regex, serialization, test, thread. And that's only compiled components (content of lib/). There are many more header-only components (i.e. subdirectories under boost/), such as spirit, variant, property_map, property_tree, dynamic_bitset. Is this really a minimal subset to use boost.python ? I can't quite believe it. In particular, what is boost.mpi doing there, and what boost.serialization (and boost.spirit) ? I'm going to great length to be able to use boost in a production environment, but I have to admit that this is quite unacceptable. :-( Stefan -- ...ich hab' noch einen Koffer in Berlin...

9 24

[math] Comeau can't match math::tools::fmod_workaround
by Mateusz Loskot 19 Jan '10

19 Jan '10

Hi, I'm not sure if I should submit this issue directly to Trac, so I decided to post it here first. Compiling Boost.Math using Comeau + GCC on Linux throws error that suggests mismatch of dobule and long double where single type T is expected: como-linux.compile.c++ ../../../bin.v2/libs/math/build/como-linux/debug/link-static/ellint_3l.o Comeau C/C++ 4.3.10.1 (May 7 2008 12:23:21) for LINUX_INTEL_ELF_Beta Copyright 1988-2008 Comeau Computing. All rights reserved. MODE:non-strict warnings C++ noC++0x_extensions "../../../boost/math/special_functions/ellint_3.hpp", line 185: error: no instance of function template "boost::math::tools::fmod_workaround" matches the argument list argument types are: (double, long double) T rphi = boost::math::tools::fmod_workaround(fabs(phi), T(constants::pi<T>() / 2)); ^ detected during instantiation of "T boost::math::detail::ellint_pi_imp(T, T, T, T, const Policy &) [with T=long double, Policy=c_policies::c_policy]" at line 309 1 error detected in the compilation of "../../../libs/math/build/../src/tr1/ellint_3l.cpp". como -tused -c --long_long -DBOOST_ALL_NO_LIB=1 -D_GNU_SOURCE=1 --no_inlining -O0 -g --exceptions -I"../../.." -I"../../../libs/math/src/tr1" -o "../../../bin.v2/libs/math/build/como-linux/debug/link-static/ellint_3l.o" "../../../libs/math/build/../src/tr1/ellint_3l.cpp" Could any one confirm if it is an error indeed? Should I submit ticket? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

2 10

[Signals2] Using dummy_mutex in a multithreaded program
by Peter Petrov 18 Jan '10

18 Jan '10

Greetings Frank, boosters, Currently using a signal with a boost::signals2:dummy_mutex works well only in single-threaded programs. I'm wondering if it can be made a little more useful. I have an use case with a single global signal, where all slots and connections are setup on program start. Afterwards a bunch of threads are fired, and each of them can call the signal's operator(). There are no more connections added/removed, only signal invocations. According to the workflow described here: http://www.boost.org/doc/libs/1_41_0/doc/html/signals2/thread-safety.html#i… ...it seems that a dummy_mutex should be enough, since the slot list is never modified. It turns out it's not - I'm getting assertion failures in nolock_cleanup_connections() because the _shared_state.unique() requirement is sometimes violated. Because using a real mutex will significantly degrade both performance and concurrency, I'm wondering if this assertion is really necessary. In this case it should be safe to continue even if the uniqueness is violated, because the connection list is never modified. And I think my use case is quite common :) - Peter

2 2

[chrono] v0.3 New Stopwatch Feature
by vicente.botet 18 Jan '10

18 Jan '10

Hi, I'm pleased to announce the new version of the Boost.Chrono library. The implementaton is quite stable; the new interface could suffer of some modifications, renaming, ... as far as you submit some proposals. I would request a formal review soon and I will need a review manager. I know that review managers are hard to find, so if you are interested in the library, please the Review Wizards. The library can be downloaded from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… and the documentation is online on the sandbox http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht…. I've tested it with gcc and MSVC. Previoous version of the library have been testted on Mac, but I'm not able to test this platform. Could someone check if there are some regressions on Mac? New Features: * Process cpu clocks * Independent process cpu clocks for real, user, system process CPU time * Global process cpu clock for real, user, system process CPU time * Stopwatch concept measuring elapsed time between different points in time associated to the operations start, stop, suspend and resume. * stopwatch is a model Stopwatch measuring the elapsed time between the start and the stop operations. * stopwatch_accumulator is a model Stopwatch allowing to accumulate several time samples and give the average, ... * Scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * Stopwatch Formatter concept * stopwatch formatter "%ds\n" * stopwatch accumulator formatter "%c times, sum%ss, min%ms, max%Ms, mean%as\n" * time formatter "real %rs, cpu %cs (%p%), user %us, system %ss\n" * digital_time decomposition class separating days, hours,minutes,seconds, nanoseconds from any duration class (looking for a better name) * digital_time formatter "%d days(s) %h:%m:%s.%n\n" * stopwatch_reporter is a convenient generic class reporting elapsed time for the Stopwatch concept. * stopclock<Clock> shortcut stopwatch_reporter<stopwatch<Clcok>> * typeof registration for classes duration and time_point Depreceated Features: * The classes process_times, process_clock, process_timer, timer and run_timer are now deprecated as the preceding additions are more generic. However for backward compatibility they are preserved until inclusion of the library in Boost. Next follows the equivalences: timer<> ~ stopwatch<> process_timer ~ stopwatch<process_cpu_clock> run_timer ~ stopclock<> Bug Fixes * Try to correct warning C4251: 'boost::chrono::run_timer::m_format' : class 'std::basic_string<_Elem,_Traits,_Ax>' needs to have dll-interface to be used by clients of class 'boost::chrono::run_timer', by don't including inlines functions using the std::string m_format. For people that doesn't know it yet, Boost.Chrono library provides: * The C++0x Standard Library's common_type. * The C++0x Standard Library's compile-time rational arithmetic. * The C++0x Standard Library's time utilities, including: * Class template duration * Class template time_point * Clocks: * system_clock * monotonic_clock * high_resolution_clock * typeof registration for classes duration and time_point * Process clocks: * process_real_CPU_clocks, capturing real-CPU times. * process_user_CPU_clocks, capturing user-CPU times. * process_system_CPU_clocks, capturing system-CPU times. * process_cpu_clock, tuple-like class capturing at once real, user-CPU, and system-CPU times. * Stopwatches: * stopwatch, capturing elapsed Clock times. * stopwatch_accumulator, capturing cummulated elapsed Clock times. * scoped helper classes allowing to pairwise start/stop operations, suspend/resume and resume/suspend a Stopwatch. * Stopclocks or Stopwatch reporters: * stopwatch_reporter, convenient reporting of models of Stopwatch results. * stopclock<Clock> shortcut of stopwatch_reporter<stopwatch<Clock>> Best regards, _____________________ Vicente Juan Botet Escribá

4 8

[inspect] Changes to Inspection Report
by Beman Dawes 18 Jan '10

18 Jan '10

The latest run of the trunk inspection report is up at http://boost.cowic.de/rc/inspect-trunk.html Several new features have been added: * References to unknown bookmarks are now detected. * Duplicate bookmarks are now detected. * Each problem detected is reported on a separate line, to make it easier to work with files that have multiple problems. For example, see the errors below in the filesystem library. Comments? --Beman filesystem libs/filesystem/doc/faq.htm: *LINK* unknown bookmark: #global libs/filesystem/doc/i18n.html: *LINK* unknown bookmark: #Footnote *LINK* unknown bookmark: #status libs/filesystem/doc/index.htm: *LINK* unknown bookmark: #path libs/filesystem/doc/reference.html: *LINK* duplicate bookmark: exists *LINK* duplicate bookmark: initial_path *LINK* unknown bookmark: #basic_directory_entry-comparisons *LINK* unknown bookmark: #operator-eq libs/filesystem/test/deprecated_test.cpp: *APPLE-MACROS* violation of Boost apple-macro guidelines on line 21 *APPLE-MACROS* violation of Boost apple-macro guidelines on line 27 libs/filesystem/test/path_test.cpp: *APPLE-MACROS* violation of Boost apple-macro guidelines on line 34 *APPLE-MACROS* violation of Boost apple-macro guidelines on line 43

8 11

[1.42] Release Notes
by Daniel James 18 Jan '10

18 Jan '10

Hi, Just a quick reminder about the release notes. This is the ideal time to add them to 'boost_1_42_0.qbk' in: https://svn.boost.org/svn/boost/website/public_html/beta/feed/history/ Or if you send them to the list and I'll add them for you. It's helpful if they're added before the beta, so that beta testers know what needs testing. thanks, Daniel

2 3

[1.42.0] Ready for beta?
by Beman Dawes 18 Jan '10

18 Jan '10

How do we look for going ahead with the beta? Unless there are concerns, I'll start putting the beta together later today. --Beman

1 0

[interval containers (itl)] found review manager. New release on sourceforge
by Joachim Faulhaber 18 Jan '10

18 Jan '10

Dear list! I am pleased to announce that Hartmut Kaiser now supports my library of interval containers as review manager. Although this was not necessarily intended, the planned date for the review already found it's way into the review schedule. But this is unofficial as long as Hartmut has not done his announcement of the review period. In preparation to the review I have done some improvements mainly for documentation of the extended parts of the itl, so I have uploaded a new release to the itl's project page on sourceforge http://sourceforge.net/projects/itl/ There are a few corrections and additions to the quickbook docs of the core library itl which is submitted for review: http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html For the extended parts there is a doxygen generated documentation http://www.herold-faulhaber.de/itl/index.html that now also contains a commented example for a law based test http://www.herold-faulhaber.de/itl/de__morgan_8cpp.html for people how are interested how this works. Any feed back, comments and suggestions are welcome. Best regards Joachim --------------------------------------------------------------------- Interval Template Library (ITL) | Boost.IntervalContainers --------------------------------------------------------------------- Availability: Project page at sourceforge: http://sourceforge.net/projects/itl/ Boost Vault: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Conta… Boost Quickbook documentation (corelibrary itl) http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html Doxygen Documentation (extensions itl_xt, validate) http://www.herold-faulhaber.de/itl/index.html The name ITL is provisional and will probably be changed to Boost.IntervalContainers after the review.

1 0

[property_tree] stream_translator <-> lexical_cast
by Domagoj Saric 18 Jan '10

18 Jan '10

By scanning briefly through the property_tree implementation I noticed that it uses its own stream_translator<> class for string-to-other_type and vice verse conversions. The functionality seems very similar/overlapping to that of lexical_cast (and also uses streams), if this is true this part of property_tree should probably be refactored to use lexical_cast so that it gets implicitly 'fixed' when/if lexical_cast gets fixed (regarding the issues outlined in the previous relevant post). -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley

1 0

Boost.Filesystem: basename function is not compatible with POSIX; potential for path-related security issues
by Steve M. Robbins 18 Jan '10

18 Jan '10

Hi, I got the following report [1] for Boost.Filesystem from a Debian user. Before entering into trac, I thought I'd ask whether this deviation from POSIX is by design or is a bug. Thanks, -Steve P.S. The original report is based on Boost 1.40, but I verified the same behaviour on Boost 1.41. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565504 ----- Forwarded message from Roger Leigh <rleigh(a)debian.org> ----- Package: libboost-filesystem1.40.0 Version: 1.40.0-5 Severity: important The basename function is not compatible with the POSIX function by the same name: Path POSIX Boost test.real test.real test /usr/bin/perl perl perl /usr/lib lib lib /usr/ usr usr usr usr / / / . . .. .. . The test program is attached. Just compile with g++ -o testbasename -lboost_filesystem testbasename.cc http://www.opengroup.org/onlinepubs/000095399/functions/basename.html ??? It is not stripping trailing backslashes. ??? "if ph.leaf() contains a dot ('.'), returns the substring of ph.leaf() starting from beginning and ending at the last dot (the dot is not included). Otherwise, returns ph.leaf()". This is wrong, shown by the paths returned for "." ("") and ".." (".") above. The latter could lead to reading and writing using the wrong path, which could have security issues if used in a secure context. This might be justification for raising the severity of this bug. Looking at the API reference, it looks like extension() and basename() may be intended to be complementary and are for splitting a filename into its main part and extension part, *not* the directory and filename components of a path. This should probably be explicitly spelled out due to the dangerous confusion which may result if used inappropriately. In particular, "." and ".." definitely need special casing--these are not extension separators and basename should return them intact; extension() should return an empty string. I noticed this when converting schroot to use the boost convenience function instead of my own. For reference, this is my version: std::string sbuild::basename (std::string name, char separator = '/') { // Remove trailing separators std::string::size_type cur = name.length(); while (cur > 0 && name[cur - 1] == separator) --cur; name.resize(cur); // Find last separator std::string::size_type pos = name.rfind(separator); std::string ret; if (pos == std::string::npos) ret = name; // No separators else if (pos == 0 && name.length() == 1 && name[0] == separator) ret = separator; // Only separators else ret = name.substr(pos + 1); // Basename only // Remove any duplicate adjacent path separators return remove_duplicates(ret, separator); } A POSIX-compatible dirname() function would nicely complement a POSIX-compatible basename() function as an addition to boost::filesystem. It looks like these are orthogonal to the existing functionality, however. Regards, Roger -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (550, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libboost-filesystem1.40.0 depends on: ii libboost-system1.40.0 1.40.0-5 Operating system (e.g. diagnostics ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.2-9 GCC support library ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 libboost-filesystem1.40.0 recommends no packages. libboost-filesystem1.40.0 suggests no packages. -- no debconf information #include <libgen.h> #include <boost/filesystem/convenience.hpp> #include <cstring> #include <iostream> #include <iomanip> int main () { const char *paths[] = { "test.real", "/usr/bin/perl", "/usr/lib", "/usr/", "usr", "/", ".", "..", 0 }; std::cout << std::setw(16) << std::left << "Path" << std::setw(16) << std::left << "POSIX" << std::setw(16) << std::left << "Boost" << '\n'; for (const char **path = &paths[0]; *path != 0; ++path) { char *bpath = strdup(*path); std::cout << std::setw(16) << std::left << *path << std::setw(16) << std::left << basename(bpath) << std::setw(16) << std::left << boost::filesystem::basename(*path) << '\n'; free(bpath); } return 0; } _______________________________________________ pkg-boost-devel mailing list pkg-boost-devel(a)lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-boost-devel ----- End forwarded message -----

2 1

String literals concatenation issue when using BOOST_CURRENT_FUNCTION
by vicente.botet 16 Jan '10

16 Jan '10

Hi, I want to define a macro as #define BOOST_CHRONO_DIGITAL_TIME_FORMAT(F) "\n" F " tokes %d day(s) %h:%m:%s.%n\n" #define BOOST_CHRONO_DIGITAL_TIME_FUNCTION_FORMAT BOOST_CHRONO_DIGITAL_TIME_FORMAT(BOOST_CURRENT_FUNCTION) I have a compile error with gcc(3.4.4 or 4.4.0) (Boost v1.41) in the following sentence const char* c= "\n" BOOST_CURRENT_FUNCTION " %d day(s) %h:%m:%s.%n\n"; C:\cygwin\boost_1_41_0\libs\chrono\example\digital_time_example.cpp: In function `int f1(long int)': C:\cygwin\boost_1_41_0\libs\chrono\example\digital_time_example.cpp:24: error: expected `;' before "__PRETTY_FUNCTION__" as well as const char* c= "\n" __PRETTY_FUNCTION__ " %d day(s) %h:%m:%s.%n\n"; The same code works as I expected with MSVC. The following code works well with gcc const char* c= "\n" "f" " %d day(s) %h:%m:%s.%n\n"; const char* c2= BOOST_CURRENT_FUNCTION; as well as this one const char* c= "\n" __FILE__" %d day(s) %h:%m:%s.%n\n"; Is there something wrong? Does gcc manage __PRETTY_FUNCTION__ and __FILE__ differently? Does someone knows a workaround? Best, _____________________ Vicente Juan Botet Escribá

2 3

[python] const-correctness and get_signature
by Jim Bosch 16 Jan '10

16 Jan '10

I've been working on an idea to provide optional const-handling in boost.python wrapped classes. It's coming along pretty well, but I've run into one major sticking point: the get_signature functions that extract the argument types of member function pointers into mpl sequences remove any cv-qualification on the hidden 'this' argument. This seems to be intentional - from the comments in python/signature.hpp: // Note that cv-qualification is dropped from // the "hidden this" argument of member functions; that is a // necessary sacrifice to ensure that an lvalue from_python converter // is used. This doesn't actually seem necessary; for a normal wrapped class, the special-case lvalue converter will always be the highest priority, and for a const member function, supporting rvalue converters as a fall-back wouldn't do any harm that I can see (and would help me out considerably). Could this be a relic from before wrapped class lvalue conversions were handled as a special case? Anyhow, if my hypothesis is correct, and there isn't a need to drop the cv-qualifiers in get_signature, I'd like to make a ticket and submit a patch to change it - but I wanted to check here first to see if maybe that breaks something else. Thanks! Jim Bosch

1 0

[release] files from previous releases (was: Re: [ Fusion ] Extra files in "release"?)
by Tobias Schwinger 15 Jan '10

15 Jan '10

Joel de Guzman wrote: > Marshall Clow wrote: >> Hey Joel -- >> >> I noticed that there are a bunch of fusion files that only exist in >> the release branch, and not in the trunk. >> Is that on purpose? > Thanks for reporting! Seems a "release procedure issue" to me; the trunk has apparently been copied over an old release where those files were still present and needed. Those files can be deleted from the release branch (gone from trunk since February 09, last changes on Fusion in June 09). I just read that the release branch is about to freeze so posting to boost.devel for the Release Managers to join in. Also, there might be similar issues for other libraries. >> boost/fusion/functional/adapter/detail/pow2_explode.hpp >> boost/fusion/functional/adapter/detail/pt_def.hpp >> boost/fusion/functional/adapter/detail/pt_undef.hpp >> boost/fusion/functional/adapter/unfused_generic.hpp >> boost/fusion/functional/adapter/unfused_lvalue_args.hpp >> boost/fusion/functional/adapter/unfused_rvalue_args.hpp >> boost/fusion/functional/generation/make_unfused_generic.hpp >> boost/fusion/functional/generation/make_unfused_lvalue_args.hpp >> boost/fusion/functional/generation/make_unfused_rvalue_args.hpp >> >> libs/fusion/doc/html/fusion/functional/adapters/unfused_generic.html >> libs/fusion/doc/html/fusion/functional/adapters/unfused_lvalue_args.html >> libs/fusion/doc/html/fusion/functional/adapters/unfused_rvalue_args.html >> libs/fusion/doc/html/fusion/functional/generation/functions/mk_unfused_genrc.html >> >> libs/fusion/doc/html/fusion/functional/generation/functions/mk_unfused_lvargs.html >> >> libs/fusion/doc/html/fusion/functional/generation/functions/mk_unfused_rvargs.html >> >> libs/fusion/doc/html/fusion/functional/generation/metafunctions/mk_unfused_genrc.html >> >> libs/fusion/doc/html/fusion/functional/generation/metafunctions/mk_unfused_lvargs.html >> >> libs/fusion/doc/html/fusion/functional/generation/metafunctions/mk_unfused_rvargs.html >> >> libs/fusion/test/functional/make_unfused_generic.cpp >> libs/fusion/test/functional/make_unfused_lvalue_args.cpp >> libs/fusion/test/functional/make_unfused_rvalue_args.cpp >> libs/fusion/test/functional/unfused_generic.cpp >> libs/fusion/test/functional/unfused_lvalue_args.cpp >> libs/fusion/test/functional/unfused_rvalue_args.cpp >> Regards, Tobias

6 14

[python] patch modules_init.hpp to expand macros
by Neal Becker 15 Jan '10

15 Jan '10

This patch replaces use of ## and # with BOOST_PP_CAT and BOOST_PP_STRINGIZE. This is needed so that python module names can be programmatically generated. https://svn.boost.org/trac/boost/ticket/3843

1 0

how to compile when using read_graphml
by Alexandre de Morais Amory 15 Jan '10

15 Jan '10

Hi, I've been trying to use the function from read_graphml from BGL. I am using the test case in http://lists.boost.org/Archives/boost/2007/04/119804.php as my first case study. Apparently it compiles ok, but there is a link error. See msg bellow: ====== aamory@gaph14:~/reps/test-tools/bgl/test/sandbox-bgl$ g++ reader_test.cc In file included from /usr/include/c++/4.4/backward/hash_set:59, from /usr/include/boost/graph/adjacency_list.hpp:25, from reader_test.cc:1: /usr/include/c++/4.4/backward/backward_warning.h:28:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. /tmp/ccgvAjHU.o: In function `void boost::read_graphml<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexProps, boost::property<boost::edge_weight_t, double, boost::no_property>, boost::no_property, boost::listS> >(std::basic_istream<char, std::char_traits<char> >&, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexProps, boost::property<boost::edge_weight_t, double, boost::no_property>, boost::no_property, boost::listS>&, boost::dynamic_properties&)': reader_test.cc:(.text._ZN5boost12read_graphmlINS_14adjacency_listINS_4vecSES2_NS_9directedSE11VertexPropsNS_8propertyINS_13edge_weight_tEdNS_11no_propertyEEES7_NS_5listSEEEEEvRSiRT_RNS_18dynamic_propertiesE[void boost::read_graphml<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexProps, boost::property<boost::edge_weight_t, double, boost::no_property>, boost::no_property, boost::listS> >(std::basic_istream<char, std::char_traits<char> >&, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, VertexProps, boost::property<boost::edge_weight_t, double, boost::no_property>, boost::no_property, boost::listS>&, boost::dynamic_properties&)]+0x3d): undefined reference to `boost::read_graphml(std::basic_istream<char, std::char_traits<char> >&, boost::mutate_graph&)' collect2: ld returned 1 exit status aamory@gaph14:~/reps/test-tools/bgl/test/sandbox-bgl$ ======= I guess there should be some library. Reading the doc in http://www.boost.org/doc/libs/1_38_0/libs/graph/doc/read_graphml.html it says that the lib "bgl-graphml" should be included, but I don't known where to find it. At the /usr/lib there is only the files libboost_graph-mt.a, libboost_graph-mt.so, libboost_graph-mt.so.1.38.0 It seems that the problem is just to correctly define the compilation command ... any help would be much appreciated. configuration: - boost 1.38.0 - ubuntu 9.10 64 bits - g++ 4.4.1 Thanks! Alexandre

2 4

[iterator] iterator_facade reference type problem
by Phil Endecott 15 Jan '10

15 Jan '10

Dear All, I have a problem with boost::iterator_facade. Here's an example: say I'm implementing an associative container that stores a sorted vector of keys and a separate sorted vector of values: template <typename KEY, typename VALUE> class vecmap { std::vector<KEY> keys; std::vector<VALUE> values; I can make an iterator for this that stores one iterator for each of the vectors: class iterator: public boost::iterator_facade<iterator, std::pair<KEY,VALUE>, boost::bidirectional_traversal_tag> { std::vector<KEY>::iterator ki; std::vector<VALUE>::iterator vi; void increment() { ++ki; ++vi; } void decrement() { --ki; --vi; } .... But what do I do about the reference type? I can't use std::pair<const KEY,VALUE>& because I'm not storing the keys and values in that way. It's almost possible to use std::pair<KEY,VALUE> for a const_iterator, but not if you want to allow the user to change the value through the reference. What I think I want to use is std::pair<KEY,VALUE&> i.e. the key is returned by value and only the value is returned by reference. But when I try this I get various cryptic errors about references to references and mpl things. So, has anyone else tried to do something like this? I wonder if boost::reference could be part of the solution. Thanks for any suggestions, Phil.

3 6

[graph][release][1.42] Debug code removal in release branch
by Jeremiah Willcock 15 Jan '10

15 Jan '10

A user reported some debugging code that had been left in Boost.Graph for a couple of releases. It is a simple patch and a really embarrassing bug to leave in. It is change 59005 in trunk: Index: read_graphviz_new.cpp =================================================================== --- read_graphviz_new.cpp (revision 59004) +++ read_graphviz_new.cpp (revision 59005) @@ -764,7 +764,7 @@ typedef boost::detail::graph::node_t vertex; typedef boost::detail::graph::edge_t edge; for (std::map<node_name, properties>::const_iterator i = r.nodes.begin(); i != r.nodes.end(); ++i) { - std::cerr << i->first << " " << props_to_string(i->second) << std::endl; + // std::cerr << i->first << " " << props_to_string(i->second) << std::endl; mg->do_add_vertex(i->first); for (properties::const_iterator j = i->second.begin(); j != i->second.end(); ++j) { mg->set_node_property(j->first, i->first, j->second); @@ -772,7 +772,7 @@ } for (std::vector<edge_info>::const_iterator i = r.edges.begin(); i != r.edges.end(); ++i) { const edge_info& ei = *i; - std::cerr << ei.source << " -> " << ei.target << " " << props_to_string(ei.props) << std::endl; + // std::cerr << ei.source << " -> " << ei.target << " " << props_to_string(ei.props) << std::endl; edge e = edge::new_edge(); mg->do_add_edge(e, ei.source.name, ei.target.name); for (properties::const_iterator j = ei.props.begin(); j != ei.props.end(); ++j) { @@ -782,7 +782,7 @@ std::map<subgraph_name, properties>::const_iterator root_graph_props_i = r.graph_props.find("___root___"); assert (root_graph_props_i != r.graph_props.end()); // Should not happen const properties& root_graph_props = root_graph_props_i->second; - std::cerr << "ending graph " << props_to_string(root_graph_props) << std::endl; + // std::cerr << "ending graph " << props_to_string(root_graph_props) << std::endl; for (properties::const_iterator i = root_graph_props.begin(); i != root_graph_props.end(); ++i) { mg->set_graph_property(i->first, i->second); } May I please put this into the release branch for 1.42? Thank you. -- Jeremiah Willcock

2 2