September 2009 - Boost - lists.preview.boost.org

14 Sep '09

i'd like to present some kind of micro optimization towards pipelined cpus traditionaly min() has an implementation like template<typename type> inline type min(type a, type b) { return a<b ? a : b; } this function (even if inlined) introduces a branch in a sequence of instructions though branch prediction algorithms do exist they will guess at most 50% of them because routine input is arbitrary since a wrong branch prediction causes pipeline stall i thought that such a useful routine like min() MUST have non-stalling (read 'non-branching') implementation i thought hard and in the end recalled a simple implementation which is called LUT (for 'look-up table') here's what i finally got: template<typename type> inline type min(type a, type b) { const type c[2] = {a, b}; return c[b<a]; } intuitively this implementation should work slower than the first one but in real life it runs faster (roughly by a factor of 2 for 4 byte types on core2duo) here's a test code: #include <vector> int main() { typedef int type; const int n = 1000000; std::vector<type> v1(n), v2(n); //filling v1 and v2 somehow type min = BIG_VALUE; for (size_t i = 0; i<n; ++i) a = min(a, min(v1[i], v2[i])); //searching minima of v1 and v2 return 0; } however for 'double' it runs ~2% slower (i think it's because creating a lut for 2 elements 8 bytes each is slower than a branch on c2d) nevertheless i think it's a great approach at least for ints also max() can implemented very similar you may skip the rest example of usage imagine we want to implement a symmetric matrix that stores only half of its elements (say upper triangle) a00 a01 a02 --- a11 a12 --- --- a22 then access requests to the lower triangle elements would be redirected to upper triangle ones here we have a constraint that actually we only have access to elements a(i, j) where i<=j must always be true (look at indices above) if we use a branch like //... return i<=j ? a(i, j) : a(j, i); we get a pipeline stall almost every time we want to access an arbitrary element however if we rewrite it carefully as //... const size_t m = min(i, j); //non-branching min() here return a(m, m + abs(int(i) - int(j))); //abs() is also //non-branching we get rid of branches at all! and we can hope a pipelined cpu will handle it better than the other (branched) implementation -- pavel

9 14

Re: [boost] Are warnings acceptable artifacts from builds?
by Vinnie 14 Sep '09

14 Sep '09

>From http://sqlite.org/testing.html#coverage "Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis consists mostly of making sure SQLite compiles without warnings, even when all warnings are enabled. SQLite is developed primarily using GCC and it does compile without warnings on GCC using the -Wall and -Wextra flags. There are occasional reports of warnings coming from VC++, however. Static analysis has not proven to be helpful in finding bugs. We cannot call to mind a single problem in SQLite that was detected by static analysis that was not first seen by one of the other testing methods described above. On the other hand, we have on occasion introduced new bugs in our efforts to get SQLite to compile without warnings. Our experience, then, is that static analysis is counter-productive to quality. In other words, focusing on static analysis (being concerned with compiler warnings) actually reduces the quality of the code. Nevertheless, we developers have capitulated to pressure from users and actively work to eliminate compiler warnings. We are willing to do this because the other tests described above do an excellent job of finding the bugs that are often introduced when removing compiler warnings, so that product quality is probably not decreased as a result."

16 31

[pool] Thread specific pool allocator
by James Bremner 14 Sep '09

14 Sep '09

I develop code to run on multiple processor machines. Moderate use of the standard template library (STL) containers cause programs to slow down when the work is split between threads running on different processors. This is because the STL default memory allocator is a thread-safe singleton and causes contention between the threads. The memory allocator provided by boost::pool_allocator is also a thread safe singleton. I have coded a thread specific memory allocator based on boost::pool and boost:thread_specific_pointer. My allocator creates a new instantiation for each thread it is used in, and so avoids contention between threads. The containers created with this allocator must be used carefully, not written to by more than one thread, because the allocator is not thread-safe ( that is the point! ) - however they provide dramatic performance improvements when my code runs on multiple processors. I do not expect my coding is to the high standard of the boost libraries, but I do believe it shows that something very useful can be done with a few lines of code. Any chance of a boost:thread_specific_pool_allocator in the near future? James Bremner

7 11

[serialization] Calling basic_streambuf::sync in basic_binary_iprimitive destructor
by Andrey Upadyshev 14 Sep '09

14 Sep '09

Hi, All! Anybody knows, does we really need to call std::basic_streambuf::sync in boost::archive::basic_binary_iprimitive destructor? Is it possible to not call it? I ask it because the call of sync with file stream buffer leads to skipping of the unreaded input data. I think it is not good, or al least it must be clear described in documentation, that binary_iarchive when used with file stream skips to the end of a stream. Andrey Upadyshev P.S. Sorry for my English

2 2

Re: [boost] C++ Manifesto
by christophe henry 13 Sep '09

13 Sep '09

> Why is there no Boost.ANTLR? Good question. I mean, if Spirit seems to you such a disservice to the community that you write the xth post about it, why not show how to do it right? I'm sure we would all benefit from it, because right now, I haven't read anything constructive in this post. At least Joel spent lots of time to offer a great library to the C++ community and I think he deserves better than such unconclusive criticism as "I think that it represents a disservice to the C++ community". Seeing from his user base, I respectfully allow myself some to disagree on that point. Now the challenge is simple: Make it better and you'll earn yourself some respect. Don't provide any alternative and land from now on in my spam box. Regards, Christophe _________________________________________________________________ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx

2 1

[thread] Obtaining thread id on Windows
by Agustín K-ballo Bergé 13 Sep '09

13 Sep '09

I've found a need to retrieve a thread id rather than a thread handle on Windows. There is no documented way to get it from the handle on XP (see http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/89728ee1-d9d… ). Would it make sense to add a get_native_id member function? Thank you. Agustín K-ballo Bergé.-

2 3

[variadic_templates][mpl]announcement:sandbox now has variadic_templates directory
by Larry Evans 12 Sep '09

12 Sep '09

There is now a sandbox directory for variadic templates: https://svn.boost.org/trac/boost/browser/sandbox/variadic_templates The tests in variadic_templates/libs/mpl/test/Jamfile have all passed. Some of those tests have been slightly modified to accommodate the variadic template version of mpl sequences. BTW, it's important to apply the gcc patch mentioned here: https://svn.boost.org/trac/boost/browser/sandbox/variadic_templates/README.… All sequences have been changed to use a new template: foldr_pack whose last argument is a parameter pack. That change also required a new binary template for each sequence: X_item_fold where X is one of: v l s m One reason for that change was to highlight the similarites of the sequences. Some other fold additions were: foldr_iter.hpp foldl_iter.hpp The foldr and foldl correspond roughly to iter_fold and reverse_iter_fold (or the other way around, I can't remember which). The reason for these additions is that they reflect more closely the way foldr and foldl are done in haskell, as indicated by the comments in the .hpp files. One useful application of the pattern expansion mentioned in section 3.6.1 of: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf is their use to easily define SEQ_c in terms of SEQ, where SEQ is any sequence. For example: template < typename Integral , Integral... Values > struct list_c : list < integral_c<Integral,Values>... > { typedef Integral value_type; }; Another addition is package_range_c.hpp which can be used to do something similar to range_c. The main motivation for this was the make_indexes on p. 16 of: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2080.pdf It was used in a prototype tuple implementation in: variadic_templates/libs/mpl/sandbox/tuple_non_recur.package_range_c.cpp Package_range_c was also useful in the implementation of unpack_args. A really interesting application of these pattern expansions might be another implementation of the cross_product template: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?CPPTM_Answer… The reason I think it would be useful is because the expansion of: integral_c<Integral,Values>... results in: integral_c<Integral,Value1> integral_c<Integral,Value2> ... integral_c<Integral,ValueN> where ValueI is the i-th element in Values... Now this is a cross product of a single element, Integral, with each element in Values...; hence, I would think that it would be a simple matter to just repeat this for any number of elements. IOW, instead of integral_c, there could be: template<typename Left, typename...Rights> struct pair_rights : pair<Left,Rights>... {}; and then that, somehow, could be done for each element in some list of Left's. Would somebody like to try this? Hope somebody else finds this useful. -regards, Larry

1 0

[iterators] zip_iterator requires random_access_iterator?
by Dean Michael Berris 12 Sep '09

12 Sep '09

Hi Everyone, According to the documentation (http://www.boost.org/doc/libs/1_40_0/libs/iterator/doc/zip_iterator.html) All iterator types in the argument IteratorTuple shall model Readable Iterator. When I use a BidirectionalIterator (list<...>::iterator) zip_iterator fails to compile, while when I use a RandomAccessIterator (vector<...>) it compiles just fine. I have a nesting like this: make_filter_iterator( filter(), make_zip_iterator( make_tuple( container.begin(), make_transform_iterator( container.begin(), function() ) ) ) The first line in the error logs is: /home/dean/boost/boost/iterator/detail/minimum_category.hpp: In instantiation of ‘boost::detail::minimum_category_impl<false, false>::apply<boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::bidirectional_traversal_tag>, boost::random_access_traversal_tag> I'm using Boost SVN trunk updated to revision 56153 -- did I find a bug? HTH -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

1 0

Build files locations, try 2
by Vladimir Prus 12 Sep '09

12 Sep '09

Some time ago, I have raised the concern that CMakeList.txt files violate directory structure requirements. See: http://thread.gmane.org/gmane.comp.lib.boost.devel/189496/ Back then, the discussion did not lead anywhere, and no further progress was made for 2.5 months. So, let me try to phrase this a bit differently. Is it fine with everybody if I move Jamfiles out of 'build' folder of every library one level higher? Thanks, Volodya

4 4

MSVC decorators still in autoconfig?
by Stephan Menzel 11 Sep '09

11 Sep '09

Hi, I am just about to migrate to 1.40 and I noticed the changed naming scheme. So the TOOLSET and BOOST_LIB_VERSION defines are missing when I build the libs (even when using layout=tagged in bjam) but the autoconfig, specifically auto_link.hpp, still includes this in MSVC's autolink feature. So as far as I can see autolink will not work in Windows, right? At least, it doesn't for me unless I change auto_link.hpp line 312 so skip this. Is this a bug or am I overlooking something important? Cheers, Stephan

3 4

C++ Manifesto
by Christian Schladetsch 11 Sep '09

11 Sep '09

I wrote: A problem seems to be that we are trying to be meta-meta when meta- alone suffices. > The GCC frontend hasn't been integrated into mainline GCC, the LLVM > frontend is beta and similarly lives out of tree. A substantial, > incompatible, rewrite of the language is currently in progress. > The same can be said for C++0x. And LLVM is not in beta w.r.t Apple. > > I've used D for some fun side projects, it is a nicer language than C++. > However, would I suggest using it at work, and risking a major, long-living > software project on it? Unfortunatly not yet, and most people I've > personally spoken to agree. > I am speaking out of my backside when I say anything on this matter, as I have not written anything substantial in D. But my original point remains: why not? There are no tablets written in stone stating Thou Shalt Write In C++. Sure, there are many people that are "language lawyers" and understand the finer intricacies of ADL and that is their livelihood. Great for them. Most of us understand (or could understand) most of boost. It isn't that hard - most of the "chicanery" is to do with xplat systems creating code-paths that even the original authors don't understand. The rest of the magic is in Spirit and similar expression-template-based systems that are only hard to understand because of their working domain. If they were written procedurally, they would be fine, or if they were written in ML they would be fine but because they are written in a strange mixture of bastardised C++ they are esoteric and deemed to be "excellent C++". I'm sorry. I don't think that Spirit is excellent C++. I think it is terribly clever C++ and I think that it represents a disservice to the C++ community. Further, I think it has singularly set back language development by years. The damage is untold - if only there was active C++ support for a system like ANTLR for the past few years rather than Spirit then maybe we wouldn't be in the mess we are in now. To be clear, I don't mean any disrespect to Joel or to the Spirit2 code-base per se. I just don't think that the C++ compiler was ever meant to be a language tool. I personally have witnessed at least two groups of coders reject a DSL-based solution because they thought that to do so "correctly" would mean using Boost.Spirit, which was beyond them. Meanwhile, ANTLR has no C++ support. It's a crying shame. Why is there no Boost.ANTLR? The question then stands: why stick with C++ for everything? What can D do in similar circumstances? (I know the immediate answer is "we don't use D" but can we please put that aside for a year). I don't know. I haven't used it. I have nothing to do with Digital Mars or Alex. I care only about writing effective code. I feel that C++?? is becoming just that. It doesn't matter that I can (eventually) understand the latest boost library, or the latest boost technique. What matters is what is the best way to write efficient code? Because I can agree with you, when you think that you are writing a lot of boilerplate nonsense to get basic things done. Move semantics and the problems that Ion is having is a case in point. I don't mean to be a misery-guts, but after having looking deeply at the issues I really don't see a way that it can be done without a language change. C++ is a fine language, but seriously, the authors didn't have any idea on how we'd use it and the differences are compounding exponentially. When C++ is no longer the best way (and yes, that is a "when" not an "if"), I would like to think that I am open-minded enough to be on that wave. Is that time sooner rather than later? Say you want to write a parser/AST walker/executor for a basic language with scoped variables and continuations. Is Boost.Spirit the best way to do so? Is it *really*? Say you want to write an object factory with persistent objects. Is Boost.Serialisation and Boost.Function the best way forward? How will you you store the functions? Say you want automatic resource management. shared_ptr<> doesn't cut it. It is too slow for single-threaded and at the same time doesn't deal with cycles. Say you want to write a geometry library. Ok, stop right there.... Is Boost.Graph the best way to make a basic DAG? I've tried all these systems. They work, there is no doubt. Do they work well, in practice? Has there been any real-world review of the efficacy of boost libraries in general? I'm sure there has, as many here could attest, but this is a biased sample set. I wonder how much and what aspects of boost are used in the wider community? I for one use foreach, shared_ptr, unordered, mpl, some fusion, and other bits and pieces. No-one in my team uses anything other than foreach and shared_ptr - and there is a lot of confusion I have to deal with relating to their use of weak_ptr<> and locking etc with that. It seems that 5 years ago I had to argue that boost was Ok to use, and I still feel like I am saying the same things. I am approaching the stage where I wonder why I continue to apologise for it. What do you use? Which parts of boost are good to use with least impact? This has turned into a manifesto against boost. I didn't mean that to be the case when I started, but so be it. I come from the real world, and there are real programmers that just don't know and don't want to deal with problems they can't solve. As a lead, I have to make technology decisions and I am clearly frustrated with the potential of both boost and C++ in general. Sometimes I think that it would be easier to just change language completely to C#/asm or D/C++/asm. I am in the position now to decide what will be the language for the next game made in company A. I am strongly tempted to make the core in C# with callouts to C++ libs for physics and render. Personally, after 20-odd years and still seeing the likes of Lucanus swing on the rope with his geometry lib, it makes me wonder if C++ is really what the real-time world needs. Regards, Christian.

9 10

scoped_allocator_ptr
by Felipe Magno de Almeida 11 Sep '09

11 Sep '09

Hi, Is there an interest in a scoped_ptr that receives a Allocator parameter? I've been needing this in some libraries I've been developing. It could use EBO for the Allocator parameter to have the same size as scoped_ptr for empty Allocators. I need a move_ptr with a Allocator parameter too. But I rather let somebody else write for now. Thanks, -- Felipe Magno de Almeida

3 6

Control of the file location for the boost::interprocess::managed_shared_memory object
by Michael Watkins 11 Sep '09

11 Sep '09

Is it possible to control the exact location of the file that is backing the shared memory created by boost::interprocess::managed_shared_memory? The issue occurs under Windows (it has not been tried yet under Linux). The problem is two processes attempting to connect to the same shared memory segment between two accounts, in specific from a program running as a service (using the system account) and a program running under a user account. The user account is running a program that needs to interface to the database that the service created. Everything seems to work fine, but the service will open the shared memory backing file in the global temp directory while the user account will open the file in their local settings temporary directory. Therefore two different segments are opened. The interim solution is to use boost::interprocess::managed_windows_shared_memory to create the shared memory, but the desire is to use the generic version for cross-platform compatibility. If the full file path could be specified when creating the memory segment, it would solve the problem. Michael Watkins _________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=PID23384::T:WLMTAGL:ON:WL:en-US:NF_BR_s…

2 4

[multi_index][serialization][Huang-Vista-x86_32_intel] Help with weird test failure
by joaquin＠tid.es 11 Sep '09

11 Sep '09

Huang-Vista-x86_32_intel toolset, which runs Intel 11.1 for Window, has this weird error on the serialization test for Boost.MultiIndex: Running 1 test case... ../libs/multi_index/test/test_serialization_template.hpp(82): error in "test_main_caller( argc, argv )": check all_indices_equal(m,m2) failed unknown location(0): fatal error in "test_main_caller( argc, argv )": std::exception: invalid signature (http://tinyurl.com/nd89x2) What I find weird is the throwing of invalid_signature, a Boost.Serialization exception that, according to docs, indicates that the beginning of a serialization file is not correct. I can't see how a problem with serializing multi_index_containers can lead to a file signature error. Any clue? Maybe the toolset maintainer can run this manually and provide more info? Thank you in advance, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[warnings] Are warnings acceptable artifacts from builds?
by Sid Sacek 11 Sep '09

11 Sep '09

Just curious, when I use certain libraries, I get compiler warnings. Are these simply acceptable during a build, or should they be reported to somebody ? The latest warning I'm seeing are: Warning 4 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<8>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 377 Warning 5 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<16>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 400 Regards, -Sid Sacek

13 52

[Boost.Breakable] Any interest in a Boost Breakable library?
by Pierre Morcello 11 Sep '09

11 Sep '09

Hello, I propose a set of macros that allow to break anywhere. Example of use of the main macro : // do something... BOOST_BREAKABLE { if (test1) { break; } if (test2) { break; } std::cout<<"this is never reached if test1==true or test2==true. "<<std::endl; // do something... } // here the program continues ... Is there any interest in such a library? Best regards, Pierre Morcello

20 44

Re: [boost] non-branching min()
by Phil Endecott 10 Sep '09

10 Sep '09

DE wrote: > template<typename type> inline > type min(type a, type b) > { > const type c[2] = {a, b}; > return c[b<a]; > } How well this performs compared to the conventional ?: implementation will depend on how the arguments are distributed. If the outcome is skewed, then branch prediction will make the conventional implementation faster. If the outcome is 50/50 (and not correlated with some other branch), then your code may do better. > here's a test code: > > #include <vector> > int main() > { > typedef int type; > const int n = 1000000; > std::vector<type> v1(n), v2(n); > //filling v1 and v2 somehow > type min = BIG_VALUE; > for (size_t i = 0; i<n; ++i) > a = min(a, min(v1[i], v2[i])); //searching minima of v1 and v2 > return 0; > } So the min(v1[i],v2[i]) is 50/50 (assuming that you fill the arrays with random values), while min(a,...) will be skewed to normally prefer the second arg after the first few cycles. Perhaps you can confirm that your code does better for the former and worse for the latter by testing e.g. a = std::min(a, my::min(v1[i], v2[i])); Is there some reason why a compiler cannot do your optimisation automatically when you write ?: expressions? Regards, Phil.

1 0

[Test] Memory leak with boost v1.40 under gcc 4.2 for x86_64 in Snow Leopard
by S Roderick 10 Sep '09

10 Sep '09

[First time poster to boost] Compiling for the default x86_64 produces a memory leak in the test framework, but the same program compiled for i386 does not. Mac OS X Snow Leopard gcc 4.2 with macports boost 1.40.0 (same memory leak seen in v1.39 macports also). The memory leak only occurs with multiple test cases or test suites. Set the define in my test program to remove the extra test case, and the leak dissappears. Could not find this problem on the list, nor the 'net. Output is: <code> sroderick@mp tmp $ g++ -o boost-test-i386 -arch i386 /opt/code/tmp/ boost-test.cpp -I/opt/local/include -g sroderick@mp tmp $ g++ -o boost-test -arch x86_64 /opt/code/tmp/boost- test.cpp -I/opt/local/include -g sroderick@mp tmp $ ./boost-test Running 2 test cases... *** No errors detected boost-test(75819) malloc: *** error for object 0x3000100300780: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap sroderick@mp tmp $ ./boost-test-i386 Running 2 test cases... *** No errors detected </code> gdb backtrace for x86_64 program is: <code> (gdb) bt #0 0x00007fff83180096 in __kill () #1 0x00007fff832210c2 in abort () #2 0x00007fff83138215 in free () #3 0x000000010006979e in boost::unit_test::framework_impl::clear (this=0x1000d99c0) at framework.ipp:133 #4 0x000000010006989c in boost::unit_test::framework_impl::~framework_impl (this=0x1000d99c0) at framework.ipp:122 #5 0x000000010006ae0e in __tcf_1 () at framework.ipp:225 #6 0x00007fff831443f4 in __cxa_finalize () #7 0x00007fff8314430c in exit () #8 0x0000000100009703 in start () at unit_test_parameters.ipp:172 </code> Program is: <code> #define BOOST_TEST_MODULE example #include <boost/test/included/unit_test.hpp> BOOST_AUTO_TEST_SUITE( test_suite ) BOOST_AUTO_TEST_CASE( test_case1 ) { // BOOST_ERROR( "some error 1" ); BOOST_CHECK( true ); } BOOST_AUTO_TEST_SUITE_END() #if 1 BOOST_AUTO_TEST_CASE( test_case_on_file_scope ) { BOOST_CHECK( true ); } #endif </code>

1 0

Iterators Must Go (Ahead)
by Andrei Alexandrescu 10 Sep '09

10 Sep '09

Hello, I wrote an article about D's ranges, contrasting them to other iteration idioms. Those who'd be interested in reviewing the article, please send me email. (I may not be able to reply to all requests.) Bear in mind that the article is rather long - about the size of two usual magazine articles. Thanks, Andrei

7 6

[unordered] please don't allocate memory in the default constructor
by Thorsten Ottosen 10 Sep '09

10 Sep '09

Hi Jeremy, I think this a really bad idea to allocate in the default construtor. The user can always call rehash() on the empty container, just like when we call reserve() for vector. Thanks -Thorsten

5 8

[PropertyTree] Help tracking down test failure.
by Sebastian Redl 10 Sep '09

10 Sep '09

Hi, If you look at the PTree regression results: http://www.boost.org/development/tests/trunk/developer/property_tree.html you'll see that the test_property_tree test currently fails on a log of platforms, especially Darwin. An assertion fails. Since I cannot reproduce the error on any of my systems, could someone who can please send me a stack trace, and perhaps a debug print of the two objects involved? Here's the test output of one runner: http://www.boost.org/development/tests/trunk/developer/output/minion-mpi-bo… I'd like the debug representations of 'this' and 'o', please. Thank you, Sebastian

1 1

[mpl] ForwardIterator concept recursion
by Marcin Zalewski 10 Sep '09

10 Sep '09

I have been trying to implement a concept for mpl ForwardSequence, and besides the lack of const expr requirements in the latest version of concepts I have stumbled across the problem of concept recursion. One example of such recursion is the ForwardIterator [1] concept. The requirement on the next<i>::type type is that it must be a ForwardIterator. One could try to write a concept like that: concept ForwardIteratorStatic<typename I> { typename deref; typename next; requires ForwardIteratorStatic<next>; } But for the above concept, the ConceptGCC compiler gives an error. Also, this should not compile according to the latest concepts proposal that states that a concept is not defined until the closing brace of the concept body. As for now, I think that one can try to apply technique described by Doug [2]: concept IteratorStatic<typename I> { } concept ForwardIteratorStatic<typename I> : IteratorStatic<I> { typename deref; typename next; requires IteratorStatic<next>; } But to get to my question finally, I wonder if the recursion in mpl is intentional and thought out, or is it an accident that should be re-examined. If the decision was indeed thought out, I really wonder what would be a reasonable semantics of concept recursion. Cheers, Marcin [1] http://www.boost.org/doc/libs/1_40_0/libs/mpl/doc/refmanual/forward-iterato… [2] http://www.osl.iu.edu/MailArchives/conceptgcc/2007/03/0084.php

3 3

Re: [boost] [GIL] image rescale algorithms
by Est 10 Sep '09

10 Sep '09

Hi Nicolas, I used your code in Ramen (http://sourceforge.net/projects/ramenhdr/) It works great. Thank you. And now, some feedback... I think filters should be a small separate GIL extension. They are useful also for other image resampling algorithms. In clamp_channel_fn I added an overload like this: template <typename SrcChannel, typename T, typename S, typename U> void operator()(const SrcChannel& src, scoped_channel_value<T,S,U>& dst) { typedef typename channel_traits<scoped_channel_value<T,S,U>>::value_type dst_value_t; dst = dst_value_t( src); } to avoid clamping floating point channels. Another option would be to clamp only negative values. I think template <typename PixelType> struct create_accum_pixel_type : public create_accum_pixel_type<PixelType> {}; can be replaced with template <typename PixelType> struct create_accum_pixel_type {}; I had to add some typenames in front of accum_pixel_t in rescale_rows, rescale_cols and rescale to build with gcc. and I made a parallel version using Intel TBB. It's here: http://ramenhdr.svn.sourceforge.net/viewvc/ramenhdr/trunk/extern/gil/extens… Est.

2 1

[sandbox] git?
by k-oli＠gmx.de 09 Sep '09

09 Sep '09

Is a official git-repo available? boost vault uses svn

3 2

[cmake] revision 50756 failed to merge some file properties
by JOAQUIN M. LOPEZ MUÑOZ 09 Sep '09

09 Sep '09

Hi, this is a repost of a message that went unnoticed three months ago: http://lists.boost.org/boost-cmake/2009/06/0592.php and that's causing problems when merging CMake-specific stuff from trunk to release, as discussed at: http://lists.boost.org/Archives/boost/2009/08/154996.php http://lists.boost.org/Archives/boost/2009/08/155003.php CMakeLists.txt and related files in trunk do have a "svn_keywords" property with value "Id", while the counterparts in the release branch are missing this property. I guess this was an oversight when applying revision 50756: https://svn.boost.org/trac/boost/changeset/50756 Unless fixed, this is going to pop up again when the release manager prepares for 1.41. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 9

Re: [boost] Are warnings acceptable artifacts from builds?
by pete＠pcbartlett.com 09 Sep '09

09 Sep '09

On Wed 09/09/09 15:19 , Maciej Sobczak <prog(a)msobczak.com> wrote: > If a given user has a strict policy of > not > having *any* warnings during their build, then that policy is enough > to > prevent them from using Boost. I'm pretty sure that this scenario is > not > something that library authors would easily accept. > Regards, With gcc, we have chosen to include Boost using -i_system rather than -i so that /all/ Boost-generated warnings are suppressed, on the grounds that Boost developers know what they are doing and that all warnings are thus spurious. I'm interested if others think this approach is too cavalier.

2 1

Re: [boost] [warnings] Are warnings acceptable artifactsfrom builds?
by pete＠pcbartlett.com 09 Sep '09

09 Sep '09

"Stewart, Robert" <Robert.Stewart(a)sig.com> wrote: >I regularly code with two-up emacs buffers, 80 columns each. That approach also permits me to print source code -- which I do not infrequently -- >without hard to follow line breaks. Consequently, I like the 80 column limit and am frustrated by code that exceeds that limit. Printing landscape may ease your frustration somewhat.

1 0

Interest request for pointer+bit compression optimization
by vicente.botet 09 Sep '09

09 Sep '09

Hi, I have recently found in the blog of Joaquin the following optimization consisting in embed a bit into the representation of a pointer. Please read it, it is not too long (http://bannalia.blogspot.com/2008/11/optimizing-red-black-tree-color-bits.h…) I was wondering if it would be interesting to provide some generic template classes making easier this kind of optimization. We can define two templates (See below) template <typename E> struct bit_ref; template <typename T> struct pointer_ref; So instead of having enum color_type{red=false,black=true}; class rb_node { private: color_type color_; regular_rb_node_header* parent; color_type& color(){return color_;}? color_type color()const{return color_;}? rb_node*& parent(){return parent_;}? rb_node* parent() const{return parent_;} } we can compress the colot_type and the rb_node* as follows class rb_node { private: uintptr_type parentcolor_; public: bit_ref<color_type> color(){return bit_ref<color_type>(&parentcolor_);} color_type color()const{return bit_ref<color_type>(&parentcolor_);} pointer_ref<rb_node> parent(){return pointer_ref<rb_node>(&parentcolor_);} rb_node* parent() const {return pointer_ref<rb_node>(&parentcolor_);} }; Next follows the definition of the template classes template <typename E> struct bit_ref { bit_ref(uintptr_type* r_):r(r_){} operator E() const { return E(*r&uintptr_type(1)); } bit_ref& operator=(E c) { *r&=~uintptr_type(1); *r|=uintptr_type(c); return *this; } bit_ref& operator=(const bit_ref& x) { return operator=(x.operator T()); } private: uintptr_type* r; }; template <typename T> struct pointer_ref { pointer_ref(uintptr_type* r_):r(r_){} operator T*() const { return (T*)(void*)(*r&~uintptr_type(1)); } pointer_ref& operator=(T* p) { *r=((uintptr_type)(void*)p)|(*r&uintptr_type(1)); return *this; } pointer_ref& operator=(const pointer_ref& x) { return operator=(x.operator T*()); } pointer_ref operator->()const { return operator T*(); } private: uintptr_type* r; }; Thanks Joaquin for sharing simple things like this one, stable_vector and others in your Bannalia blog. _____________________ Vicente Juan Botet Escribá

12 27

Boost.CrashReport?
by Boris Schaeling 09 Sep '09

09 Sep '09

I'm looking for a C++ library which comes close to what I imagine to be the ideal crash reporting library Boost.CrashReport. :) Firefox seems to use google-breakpad but maybe some of you have been using other (C++?) libraries. Or did anyone start to work on something like Boost.CrashReport (not that I found anything in the vault)? I don't need a library to upload automatically a crash report to a website. But if an application crashs I want to tell a user to send me file X in directory Y to avoid explaining who Dr. Watson is or what 'ulimit -c' does. Boris

2 4

Boost.Swap docs missing mention of header!
by David Abrahams 09 Sep '09

09 Sep '09

http://www.boost.org/doc/libs/1_40_0/libs/utility/swap.html doesn't tell me what I need to include in order to use boost::swap. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 4

[filesystem] Windows long paths (and also API differences)
by Adam Badura 09 Sep '09

09 Sep '09

In a simple test program I used create_directories with long path (longer then MAX_PATH being equal to 260 on my machine). ANSI version (for char) threw an exception but before reaching MAX_PATH (somewhere around 255 characters however I did not test exactly). UNICODE version (for wchar_t) created as many directories as it could (as many as would make ANSI version not throw) and skipped rest without throwing anything. This seems bad. Why is it so? And is the MAX_PATH file system limitation on Windows or is it just a limitation for some API functions? Also by the way I wanted to ask why signatures of many functions differ from the documentation. For example no function takes error code parameter and thus always throws on failure (excluding the above example...). In some places I would prefer to have that parameter instead. Also copy_file does not take the third parameter allowing it to do replacing. Why is it so? I am using Boost 1.39 (1.40 does not work for me somehow, when I try to use it it gives compilation errors as I already mentioned in a previous thread) and Visual Studio 2005 on Vista machine. Adam Badura

2 2

Re: [boost] [serialization] Linker errors in trunk
by Hartmut Kaiser 08 Sep '09

08 Sep '09

> Sorry, resending as it ended up on the wrong list... > > ----------------------------- > > Since the latest changes in trunk I'm seeing linker errors while > linking with the serialization library (VS2005 SP1, > boost_serialization-vc80-mt-gd-1_40.lib): > > runtime_support.obj : error LNK2001: unresolved external symbol > "__declspec(dllimport) public: __thiscall > boost::archive::archive_exception::archive_exception(enum > boost::archive::archive_exception::_exception_code,char const *,char > const *)" > (__imp_??0archive_exception@archive@boost@@QAE@W4_exception_code@012@PB > D1@Z) > > (note the leading underscore in _exception_code) > > Which is really strange as this symbol is the only missing one. > > OTOH, the library exports the symbol: > > boost::archive::archive_exception::archive_exception( > enum boost::archive::archive_exception::exception_code, > char const *,char const *); > > (note the missing underscore in exception_code) > > If I change the first parameter of the archive_exception constructor to > be a 'int' everything builds fine. Ok, I solved it. The MS header file excpt.h has a #define exception_code _exception_code which leads to problems if not consistently included. Doh! What a mess. The bottom line is, that archive_exception.cpp needs to be compiled with exactly the same windows headers included (excpt.h gets included by windows.h) as any sources including archive_exception.hpp, which is generally not possible to ensure. The only fail-proof way I could see is to always have #if defined(BOOST_WINDOWS) #include <excpt.h> #endif inside archive_exception.hpp, globally mapping exception_code to _exception_code. Patch attached. Ok to commit? Regards Hartmut

4 9

Re: [boost] [Boost.Function] How about parallel functions?
by Kasra 08 Sep '09

08 Sep '09

>> Hi, >> >> I required to call few functions is separate threads and use the >> results. However, the code for this looks really ugly, you have to create >> threads, then join the threads when ever you require the result of the >functions. >> >> So I have created a boost.parallel_function library that does this >> seamlessly just like invoking a normal function and it only joins the >> thread when the value of the function result type is required. Is this >> library of any interest to any one? >> >> Here is the a hello world example: >> >> #include <cstdlib> >> #include <limits> >> #include <boost/parallel_function.hpp> >> using namespace boost; >> >> int F0() >> { >> volatile int x = 0; >> for(int i=0; i<std::numeric_limits<int>::max()/1024; i++) >> x ^= std::rand(); >> return (int)x; >> } >> >> >> int F2(int y) >> { >> volatile int x = 0; >> for(int i=0; i<std::numeric_limits<int>::max()/512; i++) >> x ^= std::rand(); >> return (int)x ^ y; >> } >> >> int main() >> { >> typedef boost::parallel_function< void ( ) > f0_type; >> typedef boost::parallel_function< void (int) > f1_type; >> >> f0_type f0( &::F0 ); >> f1_type f1( &::F1 ); >> >> f0_type::result_type r0 = f0(); >> f1_type::result_type r1 = f1(32); >> >> // use r0 and r1 as if they are int >> r0 += 34; >> int value = r1 *= r0 + 452; >> >> std::cout << "Hello world " << value << std::endl; >> >> return 0; >> } > >The Boost.Task library should provides the features you need. > >int main() { > > boost::task::handle<int> f0 = boost::task:async(boost:task(F0),boost::task::new_thread()); > boost::task::handle<int> f1 = boost::task:async(boost:task(F1,32),boost::task::new_thread()); > int r0=f0.get(); > int r1=f1.get(); > > r0 += 34; > int value = r1 *= r0 + 452; > > std::cout << "Hello world " << value << std::endl; > > return 0; >} > >This library is under the review schedule and will be reviewed soon. I'm >interested on the details of your implementation to compare with >Boost.Task. It will be also useful if you can take a look to Boost.task and >try so see it provides every thing you need. > >Best, >Vicente I have taken a partial look at Boost.task, however, what I don't like about the syntax is the following: > int r0=f0.get(); > int r1=f1.get(); Current implementation (hack) would make 'f0' and 'f1' the same type 'int' (in this example). So the .get() part could be omitted altogether; which seems a lot like thread.join() call! Which is accomplished by a simple implicit conversion operator to the reference of the type. A little out of topic discussion, why is there an atomic library within task? because boost.thread has one (I think). Atomic library should be written so it becomes more coherent and reduces the code size. With Best Regards Mr. Kasra Nassiri Department of Mathematics & Computer Science Imperial College London

3 2

[Graph] 1.40 Static Link Issue
by Gordon Smith 07 Sep '09

07 Sep '09

There seems to be an unused bool in fruchterman_reingold.hpp: bool vertex_migration = false; Which will cause link errors if included in more than one statically linked library. Gordon.

2 1

Move notes
by David Abrahams 07 Sep '09

07 Sep '09

Hi Ion, A few things I noticed looking through move.hpp in the sandbox 1. you static_cast in one direction but reinterpret_cast in the other. Why? 2. I think move_iterator's operator-> return type is wrong; maybe make the pointer type be the underlying iterator type instead? 3. I think its operator[] can be wrong for some iterators. See http://www.boost.org/doc/libs/1_40_0/libs/iterator/doc/iterator_facade.html… 4. bool-valued traits should be derived from an MPL integral constant, e.g. template <class T> struct is_whatever : mpl::bool_< (some compile-time expression ) > {}; Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 4

[optional] compatibility with arrays
by Craig Henderson 07 Sep '09

07 Sep '09

I am using boost::optional but have hit a problem with arrays. Using MSVC8, the definition boost::optional<char[R] > foo_; produces a compilation error: boost_1_39_0\boost/optional/optional.hpp(315) : error C2075: 'Target of operator new()' : array initialization needs curly braces boost_1_39_0\boost/optional/optional.hpp(314) : while compiling class template member function 'void boost::optional_detail::optional_base<T>::construct(const char (&))' with [ T=char [3] ] boost_1_39_0\boost/optional/optional.hpp(455) : see reference to class template instantiation 'boost::optional_detail::optional_base<T>' being compiled with [ T=char [3] ] There is no mention of non-arrays in the type requirements, so I don't know if this is specific to MSVC8, or a general/known problem? I have overcome the problem using boost::array boost::optional<boost::array<char,R> > foo_; Is there an opportunity to detect an array and substitute a boost::array for the given type? Thanks -- Craig Craig Henderson <http://craighenderson.co.uk/> http://www.craighenderson.co.uk http://www.siteupdatenotification.com

1 0

Re: [boost] [Boost.Function] How about parallel functions?
by Kasra 07 Sep '09

07 Sep '09

The example is fine thanks. However, it has syntax errors! more like typepos :D -- Kasra

1 0

Arbitrary precision arithmetic
by Scott Johnson 07 Sep '09

07 Sep '09

Greetings. This is my first post to the mailing list, so I'll try not to act stupid. :) The recent release of Boost (1.39.0), in the boost::rational library documentation, broadly hints at (and expresses a fond wish for) an arbitrary-precision integer ("bignum") library; however none currently exists within Boost. There are numerous such libraries out in the wild (many targeted towards C); though some of them are under incompatible licenses. (One interesting starting point would be libtommath, by Tom St. Denis; it appears to be a pretty robust and functional C library; which now has a C++ wrapper--albeit one that doesn't meet boost standards. It also contains numerous other useful number-theoretic functions, many of which appear to not be dependeing on the underlying bigint type. And it's in the public domain, or at least appears to be...) Searching through the mailing list, I've seen numerous references to creating such a thing, some of them dating back nearly ten years--but none yet seems to exist. This is something, I think, which would be Really Useful to add to boost. I wasn't able to locate any current boost project or proposal to create such a thing--though it's certainly possible I looked up the wrong keyword(s). So, my possibly impertinent newbie question: Is anyone (seriously) working on such a thing, for inclusion in boost? Are there any nasty (political) obstacles to such a thing being added? Thanks! -- engineer_scotty (no, not that one) If life gives you lemons, drink Hefeweizen

12 21

problems with recursive_timed_mutex and scoped lock wont compile in version 1.39
by Clark Sims 07 Sep '09

07 Sep '09

I can compile the following code fine in boost 1.33.1 but it generates compiler errors in version 1.39. I am using visual studio 2005. I will post the code, and then post the compiler errors: #include <iostream> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> #include <boost/thread/recursive_mutex.hpp> using namespace std; //using namespace boost; using boost::mutex; using boost::thread; using boost::recursive_timed_mutex; using boost::xtime; boost::recursive_timed_mutex hello_mutex; void hello( int thread_id, int iter) { cerr << thread_id << " : " << iter << endl; } void rand_xtime( xtime* xt) { xtime_get( xt, boost::TIME_UTC); //xt.nsec += (rand() % 1000000000); xt->sec += 1 + rand()%5; } void say_hello( int thread_id) { for (int iter=0; iter<5; iter++) { xtime xt; rand_xtime( &xt); thread::sleep(xt); rand_xtime( &xt); { recursive_timed_mutex &refer_hello = hello_mutex; const xtime& refer_xt = xt; recursive_timed_mutex::scoped_timed_lock lock1( refer_hello, refer_xt); if (lock1) { hello( thread_id, iter); } } } } void hello1() { say_hello( 1); } void hello2() { say_hello( 2); } int main() { boost::thread thrd1(hello1); boost::thread thrd2(hello2); thrd1.join(); thrd2.join(); return 0; } Microsoft (R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. Warning: cannot find Makefile.TimedMutex.dep cl.exe /nologo /Ob0 /W3 /EHs /MD /GR /I ".." /D NDEBUG /D WIN32 /D _CONSOLE /FD /c /Fo"Release\TimedMutex\I386\TimedMutex.obj" "TimedMutex.cpp" TimedMutex.cpp c:\boost_1_39\boost\thread\win32\basic_recursive_mutex.hpp(64) : error C2679: binary '+' : no operator found which takes a right-hand operand of type 'const boost::xtime' (or there is no acceptable conversion) c:\boost_1_39\boost/date_time/posix_time/date_duration_operators.hpp(31): could be 'boost::posix_time::ptime boost::posix_time::operator +(const boost::posix_time::ptime &,const boost::gregorian::months &)' [found using argument-dependent lookup] c:\boost_1_39\boost/date_time/date_duration_types.hpp(132): or 'boost::gregorian::date boost::date_time::months_duration<base_config>::operator +(const boost::gregorian::date &,const boost::date_time::months_duration<base_config> &)' [found using argument-dependent lookup] with [ base_config=boost::gregorian::greg_durations_config ] c:\boost_1_39\boost/date_time/posix_time/date_duration_operators.hpp(75): or 'boost::posix_time::ptime boost::posix_time::operator +(const boost::posix_time::ptime &,const boost::gregorian::years &)' [found using argument-dependent lookup] c:\boost_1_39\boost/date_time/date_duration_types.hpp(244): or 'boost::gregorian::date boost::date_time::years_duration<base_config>::operator +(const boost::gregorian::date &,const boost::date_time::years_duration<base_config> &)' [found using argument-dependent lookup] with [ base_config=boost::gregorian::greg_durations_config ] c:\boost_1_39\boost/date_time/time.hpp(139): or 'boost::posix_time::ptime boost::date_time::base_time<T,time_system>::operator +(const boost::gregorian::date_duration &) const' with [ T=boost::posix_time::ptime, time_system=boost::posix_time::posix_time_system ] c:\boost_1_39\boost/date_time/time.hpp(159): or 'boost::posix_time::ptime boost::date_time::base_time<T,time_system>::operator +(const boost::posix_time::time_duration &) const' with [ T=boost::posix_time::ptime, time_system=boost::posix_time::posix_time_system ] while trying to match the argument list '(boost::system_time, const boost::xtime)' c:\boost_1_39\boost/thread/locks.hpp(364) : see reference to function template instantiation 'bool boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::timed_lock<boost::xtime>(const Duration &)' being compiled with [ underlying_mutex_type=boost::detail::basic_timed_mutex, Duration=boost::xtime ] c:\boost_1_39\boost/thread/locks.hpp(363) : while compiling class template member function 'bool boost::unique_lock<Mutex>::timed_lock(const boost::xtime &)' with [ Mutex=boost::recursive_timed_mutex ] TimedMutex.cpp(36) : see reference to class template instantiation 'boost::unique_lock<Mutex>' being compiled with [ Mutex=boost::recursive_timed_mutex ] NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 8\VC\BIN\cl.exe"' : return code '0x2' Stop.

1 0

Testing down
by K. Noel Belcourt 07 Sep '09

07 Sep '09

Hi, I'm sorry to report that over the weekend the machine and file systems running Boost testing failed. I'm working on resurrecting the testing on another system but it may be tomorrow before testing comes back online. I apologize for the disruption. -- Noel Belcourt

1 0

[Graph] 1.40 Static Link Issue
by Gordon Smith 07 Sep '09

07 Sep '09

There seems to be an unused bool in fruchterman_reingold.hpp: bool vertex_migration = false; Which will cause link errors if included in more than one statically linked library. Gordon.

1 0

[mpi] non-char strings
by Isidor Zeuner 07 Sep '09

07 Sep '09

The last two checkouts I installed both failed passing strings through boost::mpi communication methods when the element type was not char. So maybe someone besides me will have use for the attached patch which makes it work again. I assume this way of passing strings isn't here to stay anyway since boost::serialization also handles strings. Best regards, Isidor

3 5

Release branch test results with MPI dropped on floor
by Steve M. Robbins 06 Sep '09

06 Sep '09

Hi, Now that 1.40 is out, can we get the release branch testing result scripts fixed so that they understand MPI runs? c.f. http://lists.boost.org/Archives/boost/2009/08/155466.php http://lists.boost.org/boost-testing/2009/08/6353.php Thanks, -Steve

4 4

[hs] Quickbook highlighting doesn't work in KDE 4.3
by Andrey Semashev 06 Sep '09

06 Sep '09

I'm not sure it's the right place for this, so sorry if it's off-topic. I'm trying to use Boost.HS* with Kate from KDE 4.3 on Ubuntu 9.04 but it doesn't work. There appears no "boost::hs" group in the Toost->Highlighting menu, neither does it color the quickbook files. Have anyone run into such kind of problems? PS: I successfully used Boost.HS with previous KDE versions (4.1 for sure, not sure about 4.2). This tool really helps to document the library, many thanks to the author. * http://www.drivehq.com/web/matias.capeletto/boost_hs/doc/html/index.html

2 2

Failures for GCC 4.4.1 with gnu++0x
by Beman Dawes 06 Sep '09

06 Sep '09

9 19

[Boost.Function] How about parallel functions?
by Kasra 06 Sep '09

06 Sep '09

Hi, I required to call few functions is separate threads and use the results. However, the code for this looks really ugly, you have to create threads, then join the threads when ever you require the result of the functions. So I have created a boost.parallel_function library that does this seamlessly just like invoking a normal function and it only joins the thread when the value of the function result type is required. Is this library of any interest to any one? Here is the a hello world example: #include <cstdlib> #include <limits> #include <boost/parallel_function.hpp> using namespace boost; int F0() { volatile int x = 0; for(int i=0; i<std::numeric_limits<int>::max()/1024; i++) x ^= std::rand(); return (int)x; } int F2(int y) { volatile int x = 0; for(int i=0; i<std::numeric_limits<int>::max()/512; i++) x ^= std::rand(); return (int)x ^ y; } int main() { typedef boost::parallel_function< void ( ) > f0_type; typedef boost::parallel_function< void (int) > f1_type; f0_type f0( &::F0 ); f1_type f1( &::F1 ); f0_type::result_type r0 = f0(); f1_type::result_type r1 = f1(32); // use r0 and r1 as if they are int r0 += 34; int value = r1 *= r0 + 452; std::cout << "Hello world " << value << std::endl; return 0; } With Best Regards Mr. Kasra Nassiri Department of Mathematics & Computer Science Imperial College London

3 2

Bug in date_time::subsecond_duration
by Jon Spencer 06 Sep '09

06 Sep '09

There is a needless loss of range in the constructor of date_time::subsecond_duration. The argument is multiplied by the resolution of the base_duration, which could potentially overflow, and then divided by frac_of_second. The patch below reduces the amount of overflow and is identical if one resolution is an integer multiple of the other. The same technique is used elsewhere in the file. Also see this posting on the subject (http://lists.boost.org/boost-users/2008/10/41763.php) --- boost/date_time/time_duration.hpp +++ boost/date_time/time_duration.hpp @@ -267,7 +267,7 @@ public: typedef typename base_duration::traits_type traits_type; explicit subsecond_duration(boost::int64_t ss) : - base_duration(0,0,0,ss*traits_type::res_adjust()/frac_of_second) + base_duration(0,0,0,traits_type::res_adjust()<frac_of_second?ss/(frac_of_second/traits_type::res_adjust()):ss*(traits_type::res_adjust()/frac_of_second)) {} };

1 0

Weak pointer to object not managed by a shared_ptr
by Mateusz Loskot 05 Sep '09

05 Sep '09

Hi, One of the smart pointer techniques [1] explains use of weak_ptr pointer to object not managed by a shared_ptr. [1] http://www.boost.org/doc/libs/1_40_0/libs/smart_ptr/sp_techniques.html I'm wondering what would be practical use case of that? Is it a part of any of known idioms or patterns? Also, is it valid to assume that this technique can extend lifetime of X so of the internal integral X::i_ ? Here is a simple test case based on the technique explained in the smartptr docs [1] with my questions marked using XXX tag: /// begin of program /////////////////////////////////////////////// #include <exception> #include <iostream> #include <boost/shared_ptr.hpp> #include <boost/weak_ptr.hpp> using namespace std; using namespace boost; struct null_deleter { void operator()(void const *) const { std::cout << "deleter\n"; } }; class X { public: explicit X(int i): this_(this, null_deleter()), i_(i) {} X(X const & rhs): this_(this, null_deleter()), i_(rhs.i_) {} X & operator=(X const & rhs) { i_ = rhs.i_; return *this; } weak_ptr<X> get_weak_ptr() const { return this_; } int get_i() const { return i_; } private: shared_ptr<X> this_; int i_; }; int main() { try { shared_ptr<X> spx; { X x1(7); // XXX: lifetime is extended here? spx = shared_ptr<X>(x1.get_weak_ptr()); } // XXX: No exception. x1 is still alive, so the pointer valid? cout << spx->get_i() << std::endl; } catch (bad_weak_ptr const& e) { cerr << e.what() << endl; } catch (exception const& e) { cerr << e.what() << endl; } catch (...) { cerr << "unknown error\n"; } return 0; } /// end of program /////////////////////////////////////////////// No exception is thrown and I can It seem that the lifetime of x1, automatic object, has been extended beyond its "natural" scope. Am I correct? However, if I replace retrival of shared_ptr with weak_ptr then of course bad_weak_ptr exception is thrown: shared_ptr<X> spx; weak_ptr<X> wpx; { X x1(7); wpx = x1.get_weak_ptr(); } spx = shared_ptr<X>(wpx); cout << spx->get_i() << std::endl; I'm having problems with understanding of what causes the extention of lifetime of X (so of internal X::i_ object). Is this mechanism similar to binding r-value to "const reference"? I would appreciate if anyone could help me to understand it. References to the C++ standard would be great too. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

7 9

[ptr_container] Questionable strong guarantee of ptr_map::insert()
by Kazutoshi Satoda 05 Sep '09

05 Sep '09

Hi, With current implementation of ptr_map::insert(), if an exception is thrown, the objected pointed by the passed pointer is deleted. Is this really providing strong guarantee as documented? I understand strong guarantee as described here. http://www.boost.org/community/exception_safety.html > The strong guarantee: that the operation has either completed > successfully or thrown an exception, leaving the program state exactly > as it was before the operation started. I think ptr_map::insert() doesn't provide this guarantee because deleting the object is a change of the program state. As more concrete problem, see the attached code. I couldn't find any way to provide strong guarantee for delayed_inserter::insert_ready() using ptr_map. I want ready_value unchanged if an exception is thrown during the insertion. Looking for a solution on a similar situation, I found constructors of shared_ptr. Its documentation clearly says that "If an exception is thrown, delete p is called". And for auto_ptr version, it provides strong guarantee by taking the auto_ptr as non-const reference. I think ptr_map::insert() should follow this manner; document the deletion on exception for raw pointer version, and provide strong guarantee with insert(const key_type& key, std::auto_ptr<U>& x) . The the auto_ptr& version can be a better replacement of the raw pointer version. The required temporary of auto_ptr, instead of key_type, is more expressive (about the purpose of the temporary), and matches the Best Practices shown in the documentation of shared_ptr. http://www.boost.org/libs/smart_ptr/shared_ptr.htm#BestPractices But, introducing the auto_ptr& version seems to cause some change of behavior in client codes using the current pass-by-value version. Is it valid to request (create a ticket) for strong guaranteed (taking auto_ptr&) version while having this compatibility concern? Regards. -- k_satoda #include <memory> #include "boost/ptr_container/ptr_map.hpp" namespace ptr_map_insert_strong_guarantee_demo { class value { public: explicit value(int source); // ... }; class delayed_inserter { public: // ... // This is called from context that knows key and source of value, // but doesn't know the time of insertion. void ready_new(int key, int source) { // OK. // This implementation offers strong guarantee for this call. std::auto_ptr<value> new_value(new value(source)); ready_key = key; ready_value = new_value; } // This is called from context which doesn't know key and value, // but knows the time of insertion. void insert_ready() { if (ready_value.get() != 0) { // I want to offer strong guarantee for this call, // but boost::ptr_map deosn't provide the way to do that; // *** ready_value is deleted when an exception is thrown. *** map.insert(ready_key, ready_value); } } // ... private: int ready_key; std::auto_ptr<value> ready_value; boost::ptr_map<int, value> map; // ... }; }

8 17

[lockfree] how many items are queued?
by Oliver Kowalke 05 Sep '09

05 Sep '09

lockfree.fifo provides the info if the queue is empty or not. is it possible to provide a function std::size_t size() const - returning how many items are queued at a specific timepoint? regards, Oliver -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

5 9

PropertyTree automated tests
by Sebastian Redl 04 Sep '09

04 Sep '09

Hi, There are no test results at all for the proptree library on trunk. There isn't even a row in the table for it. Why is that so? Sebastian

2 2

wait-free fast-pathed, bounded-time, 100% starvation-free rw-mutex...
by Chris M. Thomasson 04 Sep '09

04 Sep '09

I was wondering if the following invention of mine might be of use to Boost: http://software.intel.com/en-us/forums/intel-threading-building-blocks/topi… (please __read_all__; thank you) Here are some performance numbers wrt my algorithm versus NPTL on Linux (fedora 10), and OpenSolaris: http://groups.google.com/group/comp.programming.threads/msg/3e7531657a11baf0 My invention has some very interesting properties that simply do not exist for 99% of all the other rw-mutex algorithms I have seen to date. It's 100% starvation free and has bounded wait time for readers and writers. Heck, even the Microsoft rw-mutex algorithm in Vista does not come close to that: http://msdn.microsoft.com/en-us/library/aa904937(VS.85).aspx They clearly state that their algorithm is not fair. The algorithm I have observed in OpenSolaris does not meet this goal as well. Another nice property is that the algorithm has wait-free fast-paths. If readers hit a fast-path, then they are going to get wait-free access to the protected data-structure. The same goes for writers. The underlying operation is a single atomic fetch-and-add operation: http://software.intel.com/en-us/forums/intel-threading-building-blocks/topi… In fact, the algorithm only needs fetch-and-add; no stupid CAS-loops are required. Please take not that there are absolutely no loops in the algorithm; this is one reason why it's bounded time and starvation free. Also, it has conditional reader-to-writer upgrades and non-conditional writer-to-reader downgrade capabilities. This is something that does not exist in the Microsoft implementation, or even the OpenSolaris, or basically any Linux implementation I have observed. Same goes for OSX. Therefore, I think this particular algorithm might be of use to Boost. Any thoughts? Thank you all for you're valuable time; I really do appreciate it! :^)

4 14

1.40 regex
by Jonathan Brannan 04 Sep '09

04 Sep '09

I have code that comes out clean in 1.39 (as unit-test and under valgrind), but under 1.40 it's not clean in valgrind and it crashes when run normally (malloc(): memory corruption). I'm trying to write a reproducer that is smaller than what I have, but incase something pops out at someone (or can point me where my code might be wrong), here is the valgrind output: Running 16 test cases... ==25074== Invalid write of size 8 ==25074== at 0x4E7D4A8: boost::shared_ptr<boost::re_detail::named_subexpressions_base<char> >::shared_ptr() (shared_ptr.hpp:182) ==25074== by 0x4E813C1: boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char cons t*, std::string> > > >::match_results(std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > const&) (match_results.hpp:77) ==25074== by 0x5811371: boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator <char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_rege x_traits<char> > > const&, boost::regex_constants::_match_flags) (perl_matcher_common.hpp:73) ==25074== by 0x4E856D2: boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator <char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::perl_matcher(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::_ _normal_iterator<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_i terator<char const*, std::string> > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, _ _gnu_cxx::__normal_iterator<char const*, std::string>) (perl_matcher.hpp:366) ==25074== by 0x4E8583A: bool boost::regex_search<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterat or<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char c onst*, std::string> > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, __gnu_cxx::__no rmal_iterator<char const*, std::string>) (regex_search.hpp:55) ==25074== by 0x4E85BEF: boost::regex_token_iterator_implementation<__gnu_cxx::__normal_iterator<char const*, std::string>, char, boost::regex_traits<char, boost::cpp_regex _traits<char> > >::init(__gnu_cxx::__normal_iterator<char const*, std::string>) (regex_token_iterator.hpp:109) ==25074== by 0x4E8AC07: boost::regex_token_iterator<__gnu_cxx::__normal_iterator<char const*, std::string>, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::regex_token_iterator(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::basic_regex<char, boost::regex _traits<char, boost::cpp_regex_traits<char> > > const&, int, boost::regex_constants::_match_flags) (regex_token_iterator.hpp:200) ==25074== by 0x45D99C: application_ut_suite::test_logon::test_method() (application_ut.cpp:139) ==25074== Address 0x6a64588 is 0 bytes after a block of size 56 alloc'd ==25074== at 0x4C2506C: operator new(unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==25074== by 0x5811362: boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator <char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_rege x_traits<char> > > const&, boost::regex_constants::_match_flags) (perl_matcher_common.hpp:73) ==25074== by 0x4E856D2: boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator <char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::perl_matcher(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::_ _normal_iterator<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_i terator<char const*, std::string> > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, _ _gnu_cxx::__normal_iterator<char const*, std::string>) (perl_matcher.hpp:366) ==25074== by 0x4E8583A: bool boost::regex_search<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterat or<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char c onst*, std::string> > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, __gnu_cxx::__no rmal_iterator<char const*, std::string>) (regex_search.hpp:55) ==25074== by 0x4E85BEF: boost::regex_token_iterator_implementation<__gnu_cxx::__normal_iterator<char const*, std::string>, char, boost::regex_traits<char, boost::cpp_regex _traits<char> > >::init(__gnu_cxx::__normal_iterator<char const*, std::string>) (regex_token_iterator.hpp:109) ==25074== by 0x4E8AC07: boost::regex_token_iterator<__gnu_cxx::__normal_iterator<char const*, std::string>, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::regex_token_iterator(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::basic_regex<char, boost::regex _traits<char, boost::cpp_regex_traits<char> > > const&, int, boost::regex_constants::_match_flags) (regex_token_iterator.hpp:200) ==25074== by 0x442E4F: application_ut_suite::(anonymous namespace)::Test_Setup::Test_Setup(std::istream&, unsigned long) (application_ut.cpp:96) ==25074== by 0x45D99C: application_ut_suite::test_logon::test_method() (application_ut.cpp:139) ==25074== by 0x45F620: _ZN20application_ut_suiteL18test_logon_invokerEv (application_ut.cpp:133) ==25074== ==25074== Invalid write of size 8 ==25074== at 0x46CE8A: boost::detail::shared_count::shared_count() (shared_count.hpp:71) ==25074==:regex_traits<char, boost::cpp_regex_traits<char> > > const&, int, boost::regex_constants::_match_flags) (regex_token_iterator.hpp:200) ==25074== by 0x442E4F: application_ut_suite::(anonymous namespace)::Test_Setup::Test_Setup(std::istream&, unsigned long) (application_ut.cpp:96) ==25074== Address 0x6a64590 is 8 bytes after a block of size 56 alloc'd ==25074== at 0x4C2506C: operator new(unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==25074== by 0x5811362: boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags) (perl_matcher_common.hpp:73) ==25074== by 0x4E856D2: boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::perl_matcher(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::_cxx::__normal_iterator<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, __gnu_cxx::__normal_iterator<char const*, std::string>) (regex_search.hpp:55) ==25074== by 0x4E85BEF: boost::regex_token_iterator_implementation<__gnu_cxx::__normal_iterator<char const*, std::string>, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::init(__gnu_cxx::__normal_iterator<char const*, std::string>) (regex_token_iterator.hpp:109) ==25074== by 0x4E8AC07: boost::regex_token_iterator<__gnu_cxx::__normal_iterator<char const*, std::string>, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::regex_token_iterator(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, int, boost::regex_constants::_match_flags) (regex_token_iterator.hpp:200) ==25074== by 0x442E4F: application_ut_suite::(anonymous namespace)::Test_Setup::Test_Setup(std::istream&, unsigned long) (application_ut.cpp:96) ==25074== by 0x45D99C: application_ut_suite::test_logon::test_method() (application_ut.cpp:139) ==250ub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags) (perl_matcher_common.hpp:73) ==25074== by 0x4E856D2: boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::perl_matcher(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, __gnu_cxx::__normal_iterator<char const*, std::string>) (perl_matcher.hpp:366) ==25074== by 0x4E8583A: bool boost::regex_search<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, __gnu_cxx::__normal_iterator<char const*, std::string>) (regex_search.hpp:55) ==25074== by 0x4E85BEF: boost::regex_token_iterator_implementation<__gnu_cxx::__normal_iterator<char const*, std::string>, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::init(__gnu_cxx::__normal_iterator<char const*, snstants::_match_flags) (regex_token_iterator.hpp:200) ==25074== by 0x442E4F: application_ut_suite::(anonymous namespace)::Test_Setup::Test_Setup(std::istream&, unsigned long) (application_ut.cpp:96) ==25074== by 0x45D99C: application_ut_suite::test_logon::test_method() (application_ut.cpp:139) ==25074== by 0x45F620: _ZN20application_ut_suiteL18test_logon_invokerEv (application_ut.cpp:133) ==25074== Address 0x6a64598 is not stack'd, malloc'd or (recently) free'd **25074** new/new[] failed and should throw an exception, but Valgrind cannot throw exceptions and so is aborting instead. Sorry. ==25074== at 0x4C22E23: (within /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==25074== by 0x4C250C8: operator new(unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==25074== by 0x4E84680: __gnu_cxx::new_allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >::allocate(unsigned long, void const*) (new_allocator.h:92) ==25074== by 0x4E846AF: std::_Vector_base<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >::_M_allocate(unsigned long) (stl_vector.h:144) ==25074== by 0x4E8A4AE: std::vector<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*tor.tcc:395) ==25074== by 0x4E8A61E: std::vector<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >::insert(__gnu_cxx::__normal_iterator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> >*, std::vector<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > > >, unsigned long, boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > const&) (stl_vector.h:792) ==25074== by 0x4E8A73B: boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >::set_size(unsigned long, __gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>) (match_results.hpp:399) ==25074== by 0x4E8B1BF: boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::find_imp() (perl_matcher_common.hpp:263) ==25074== by 0x5810D0A: boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::find() (perl_matcher_common.hpp:229) ==25074== by 0x4E85846: bool boost::regex_search<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost:::regex_traits<char, boost::cpp_regex_traits<char> > >::init(__gnu_cxx::__normal_iterator<char const*, std::string>) (regex_token_iterator.hpp:109) ==25074== by 0x4E8AC07: boost::regex_token_iterator<__gnu_cxx::__normal_iterator<char const*, std::string>, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::regex_token_iterator(__gnu_cxx::__normal_iterator<char const*, std::string>, __gnu_cxx::__normal_iterator<char const*, std::string>, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, int, boost::regex_constants::_match_flags) (regex_token_iterator.hpp:200) ==25074== ==25074== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 3 from 1) ==25074== malloc/free: in use at exit: 64,694 bytes in 500 blocks. ==25074== malloc/free: 590 allocs, 89 frees, 103,110 bytes allocated. ==25074== For counts of detected errors, rerun with: -v ==25074== searching for pointers to 500 not-freed blocks. ==25074== checked 402,856 bytes. ==25074== ==25074== LEAK SUMMARY: ==25074== definitely lost: 0 bytes in 0 blocks. ==25074== possibly lost: 7,480 bytes in 190 blocks. ==25074== still reachable: 57,214 bytes in 310 blocks. ==25074== suppressed: 0 bytes in 0 blocks. ==25074== Rerun with --leak-check=full to see details of leaked memory.

2 2

[1.41.0] Release branch open for merges
by Beman Dawes 04 Sep '09

04 Sep '09

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, except for new libraries, merging changes *does not* need permission from a release manager. I.e. just do it! The release schedule is more aggressive than usual on the front end so that we can maintain our quarterly release schedule: * September 13, 2009: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * September 20, 2009: Release managers start QA checks. * October 4, 2009: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * October 11, 2009: branches/release closed for all library changes except when specific permission given by release manager(s). * October 18, 2009: Beta release target date. Further betas and/or release candidates as feedback dictates. * November 1, 2009: Release ship date. Links relating to this release: * Google Calendar with the release schedule: <http://www.boost.org/development/index.html>. * Release schedule explanation: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>. * Release practices for developers: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>. -- The release managers

3 3

Re: [boost] question about TMP
by DE 04 Sep '09

04 Sep '09

for those who is still interested i thought about types that a library user can actually use and finally came to this decision one can use something like //don't look at syntax, check out the concept matrix<double> m; //general rectangular dense matrix matrix<double, sparse> sp; //rectangular sparse matrix square<double> sq; //square matrix, although one might square<double, symmetric> sym; //use the following types which square<double, upper_triang> ut; //model corresponding concepts square<double, lower_triang> lt; //i.e. symmetric, upper- & lower //triangular matrices square<double, symmetric | sparse> sparse_sym; //also this square<double, lower_triang | sparse> sparse_lt;//might be useful band<double> b; //guess... band<double, symmetric> bs; //why not? //etc... all these types provide strict explicit interfaces e.g. - 'square' provides 'resize(size_t)' member but not 'resize(size_t, size_t)' - 'band' provides useful 'bandwidth()' member and 'diagonal(int)' member which returns diagonal (might be useful for implementing a band solver) -- Pavel

1 0

optional<optional<T>>
by Andrei Alexandrescu 04 Sep '09

04 Sep '09

Hello, I'm defining an "optional" type for D's standard library modeled similarly to Boost.optional. An interesting question came up - should optional<optional<T>> fold itself into optional<T>, or is "double optional" an interesting concept of its own? I thought I'd ask here because by now there's a significant body of experience with optional<T>. I perused the online documentation and the forum and couldn't find information about that specific detail. Thanks, Andrei

14 22

Re: [boost] [ublas] Extending type_traits for use with Boost Units
by Matthias Schabel 04 Sep '09

04 Sep '09

> Am Wednesday 26 August 2009 schrieb Manoj Rajagopalan: >> Hi UBLAS developers, >> >> I have begun using Boost Units which was introduced in boost v >> 1.36. I am working on extending UBLAS to support physically >> dimensioned types and I have provided a short example below. >> >> This can be achieved efficiently if a few extensions to UBLAS >> type_traits are allowed and I was wondering if anyone would object to >> this. An example of such an extension would be the introduction of >> "sqrt_type" as the type for the square root operation. This would be >> the return type for type_traits<T>::type_sqrt(). For arithmetic types >> like float and double the template can be partially specialized so >> that sqrt_type is float or double but for physically dimensioned >> types like quantity<length,double>, sqrt_type can be set to >> quantity<length^(1/2), double>. > > This is a good idea. Could you prepare a patch and a small example > program? > >> I have already adapted most of vector_expression.hpp for use with >> these dimensioned quantities with work-arounds for these extensions >> but this is getting ugly and unwieldy. > > is it possible to deduct the square_type from operator*()? E.g., using > return type deduction (see detail/returntype_deduction and > promote_traits from traits.hpp) You might also want to get in touch with Steven Watanabe. I believe he has done some work toward making UBLAS and Boost.Units interoperable. Matthias

2 1

Re: [boost] [Polygon] What does this error mean?
by Phil Endecott 03 Sep '09

03 Sep '09

Dear Luke (& others), Here's some test code, followed by the errors that I get when I try to compile it. It boils down to some confusion about whether set is a type or a function. Am I doing something that isn't allowed? Thanks for any suggestions. #include <boost/polygon/polygon.hpp> template<typename COORD_T> struct Box { typedef COORD_T coord_t; coord_t x0; coord_t y0; coord_t x1; coord_t y1; }; typedef int screen_coord_t; typedef Box<screen_coord_t> screen_box_t; namespace boost { namespace polygon { template <> struct geometry_concept<screen_box_t> { typedef rectangle_concept type; }; template <> struct rectangle_traits<screen_box_t> { typedef screen_coord_t coordinate_type; typedef std::pair<screen_coord_t,screen_coord_t> interval_type; static inline interval_type get(const screen_box_t& rectangle, orientation_2d orient) { return (orient==HORIZONTAL) ? std::make_pair(rectangle.x0,rectangle.x1) : std::make_pair(rectangle.y0,rectangle.y1); } }; }; }; typedef boost::polygon::polygon_90_set_data<screen_coord_t> markers_t; markers_t markers; void draw_marker(screen_box_t sb) { using namespace boost::polygon::operators; markers |= sb; } /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_set.h: In function ‘typename boost::enable_if<typename boost::polygon::gtl_and_3<boost::polygon::y_r_assign, typename boost::polygon::is_mutable_rectangle_concept<typename boost::polygon::geometry_concept<T>::type>::type, typename boost::polygon::is_rectangle_concept<typename boost::polygon::geometry_concept<T2>::type>::type>::type, rectangle_type_1>::type& boost::polygon::assign(rectangle_type_1&, const rectangle_type_2&) [with rectangle_type_1 = boost::polygon::rectangle_data<int>, rectangle_type_2 = Box<int>]’: /usr/local/src/gtl/boost/polygon/detail/iterator_geometry_to_set.hpp:34: instantiated from ‘boost::polygon::iterator_geometry_to_set<boost::polygon::rectangle_concept, rectangle_type>::iterator_geometry_to_set(const rectangle_type&, boost::polygon::direction_1d, boost::polygon::orientation_2d, bool) [with rectangle_type = Box<int>]’ /usr/local/src/gtl/boost/polygon/polygon_90_set_data.hpp:137: instantiated from ‘void boost::polygon::polygon_90_set_data<T>::insert(const geometry_type&, bool, boost::polygon::orientation_2d) [with geometry_type = Box<int>, T = int]’ /usr/local/src/gtl/boost/polygon/polygon_90_set_data.hpp:113: instantiated from ‘void boost::polygon::polygon_90_set_data<T>::insert(iT, iT, boost::polygon::orientation_2d) [with iT = const Box<int>*, T = int]’ /usr/local/src/gtl/boost/polygon/detail/polygon_90_set_view.hpp:318: instantiated from ‘typename boost::enable_if<typename boost::polygon::gtl_and<boost::polygon::operators::y_ps90_pe, typename boost::polygon::is_polygon_90_set_type<polygon_set_type_2>::type>::type, boost::polygon::polygon_90_set_data<coordinate_type> >::type& boost::polygon::operators::operator+=(boost::polygon::polygon_90_set_data<coordinate_type>&, const geometry_type_2&) [with coordinate_type_1 = int, geometry_type_2 = Box<int>]’ /usr/local/src/gtl/boost/polygon/detail/polygon_90_set_view.hpp:329: instantiated from ‘typename boost::enable_if<typename boost::polygon::gtl_and<boost::polygon::operators::y_ps90_be, typename boost::polygon::is_polygon_90_set_type<polygon_set_type_2>::type>::type, boost::polygon::polygon_90_set_data<coordinate_type> >::type& boost::polygon::operators::operator|=(boost::polygon::polygon_90_set_data<coordinate_type>&, const geometry_type_2&) [with coordinate_type_1 = int, geometry_type_2 = screen_box_t]’ testpoly.cc:41: instantiated from here /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_set.h:71: error: ‘template<class _Key, class _Compare, class _Alloc> class std::set’ is not a function, /usr/local/src/gtl/boost/polygon/point_concept.hpp:77: error: conflict with ‘template<class T, class coordinate_type> void boost::polygon::set(T&, boost::polygon::orientation_2d, coordinate_type, typename boost::enable_if<typename boost::polygon::is_mutable_point_concept<typename boost::polygon::geometry_concept<T>::type>::type, void>::type*)’ /usr/local/src/gtl/boost/polygon/rectangle_concept.hpp:192: error: in call to ‘set’ /usr/local/src/gtl/boost/polygon/detail/iterator_geometry_to_set.hpp:34: instantiated from ‘boost::polygon::iterator_geometry_to_set<boost::polygon::rectangle_concept, rectangle_type>::iterator_geometry_to_set(const rectangle_type&, boost::polygon::direction_1d, boost::polygon::orientation_2d, bool) [with rectangle_type = Box<int>]’ /usr/local/src/gtl/boost/polygon/polygon_90_set_data.hpp:137: instantiated from ‘void boost::polygon::polygon_90_set_data<T>::insert(const geometry_type&, bool, boost::polygon::orientation_2d) [with geometry_type = Box<int>, T = int]’ /usr/local/src/gtl/boost/polygon/polygon_90_set_data.hpp:113: instantiated from ‘void boost::polygon::polygon_90_set_data<T>::insert(iT, iT, boost::polygon::orientation_2d) [with iT = const Box<int>*, T = int]’ /usr/local/src/gtl/boost/polygon/detail/polygon_90_set_view.hpp:318: instantiated from ‘typename boost::enable_if<typename boost::polygon::gtl_and<boost::polygon::operators::y_ps90_pe, typename boost::polygon::is_polygon_90_set_type<polygon_set_type_2>::type>::type, boost::polygon::polygon_90_set_data<coordinate_type> >::type& boost::polygon::operators::operator+=(boost::polygon::polygon_90_set_data<coordinate_type>&, const geometry_type_2&) [with coordinate_type_1 = int, geometry_type_2 = Box<int>]’ /usr/local/src/gtl/boost/polygon/detail/polygon_90_set_view.hpp:329: instantiated from ‘typename boost::enable_if<typename boost::polygon::gtl_and<boost::polygon::operators::y_ps90_be, typename boost::polygon::is_polygon_90_set_type<polygon_set_type_2>::type>::type, boost::polygon::polygon_90_set_data<coordinate_type> >::type& boost::polygon::operators::operator|=(boost::polygon::polygon_90_set_data<coordinate_type>&, const geometry_type_2&) [with coordinate_type_1 = int, geometry_type_2 = screen_box_t]’ testpoly.cc:41: instantiated from here /usr/local/src/gtl/boost/polygon/rectangle_concept.hpp:192: error: no matching function for call to ‘set(boost::polygon::rectangle_data<int>&, boost::polygon::orientation_2d_enum, std::pair<int, int>)’ /usr/local/src/gtl/boost/polygon/detail/iterator_geometry_to_set.hpp:34: instantiated from ‘boost::polygon::iterator_geometry_to_set<boost::polygon::rectangle_concept, rectangle_type>::iterator_geometry_to_set(const rectangle_type&, boost::polygon::direction_1d, boost::polygon::orientation_2d, bool) [with rectangle_type = Box<int>]’ /usr/local/src/gtl/boost/polygon/polygon_90_set_data.hpp:137: instantiated from ‘void boost::polygon::polygon_90_set_data<T>::insert(const geometry_type&, bool, boost::polygon::orientation_2d) [with geometry_type = Box<int>, T = int]’ /usr/local/src/gtl/boost/polygon/polygon_90_set_data.hpp:113: instantiated from ‘void boost::polygon::polygon_90_set_data<T>::insert(iT, iT, boost::polygon::orientation_2d) [with iT = const Box<int>*, T = int]’ /usr/local/src/gtl/boost/polygon/detail/polygon_90_set_view.hpp:318: instantiated from ‘typename boost::enable_if<typename boost::polygon::gtl_and<boost::polygon::operators::y_ps90_pe, typename boost::polygon::is_polygon_90_set_type<polygon_set_type_2>::type>::type, boost::polygon::polygon_90_set_data<coordinate_type> >::type& boost::polygon::operators::operator+=(boost::polygon::polygon_90_set_data<coordinate_type>&, const geometry_type_2&) [with coordinate_type_1 = int, geometry_type_2 = Box<int>]’ /usr/local/src/gtl/boost/polygon/detail/polygon_90_set_view.hpp:329: instantiated from ‘typename boost::enable_if<typename boost::polygon::gtl_and<boost::polygon::operators::y_ps90_be, typename boost::polygon::is_polygon_90_set_type<polygon_set_type_2>::type>::type, boost::polygon::polygon_90_set_data<coordinate_type> >::type& boost::polygon::operators::operator|=(boost::polygon::polygon_90_set_data<coordinate_type>&, const geometry_type_2&) [with coordinate_type_1 = int, geometry_type_2 = screen_box_t]’ testpoly.cc:41: instantiated from here /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_set.h:71: error: ‘template<class _Key, class _Compare, class _Alloc> class std::set’ is not a function, /usr/local/src/gtl/boost/polygon/point_concept.hpp:77: error: conflict with ‘template<class T, class coordinate_type> void boost::polygon::set(T&, boost::polygon::orientation_2d, coordinate_type, typename boost::enable_if<typename boost::polygon::is_mutable_point_concept<typename boost::polygon::geometry_concept<T>::type>::type, void>::type*)’ /usr/local/src/gtl/boost/polygon/rectangle_concept.hpp:193: error: in call to ‘set’ /usr/local/src/gtl/boost/polygon/rectangle_concept.hpp:193: error: no matching function for call to ‘set(boost::polygon::rectangle_data<int>&, boost::polygon::orientation_2d_enum, std::pair<int, int>)’

6 12

[1.41.0] New libraries?
by Beman Dawes 03 Sep '09

03 Sep '09

Are there any new libraries that will be ready for 1.41.0? There is a New Library Checklist that needs to be gone over with the release managers before merging new libraries into branches/release. See http://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList#NewL… Thanks, --Beman

2 1

[graph] quickbook reference docs and formatting
by Andrew Sutton 03 Sep '09

03 Sep '09

Jeremiah, Nick, others with opinions.... Two questions: First, I need a second opinion on some formatting alternatives for the quickbook docs w.r.t the documentation of member/non-member functions of the graph classes. These should be mostly buildable - there are some errors about missing links, but they aren't fatal. Let me know if there are issues building them. I got the doc toolchain working a while ago and I'm afraid to mess with it. I may not have the same set up as everybody else. Hopefully I do. The HTML docs give a flat listing with each function separated by a HR element, which is effective (although not especially navigable). Other lib**raries (e.g., Boost.Filesystem) present a similar listing although without the HR's to divide the content. I've tried putting these in a table to improve readability, and it works a little but, but I don't have enough control over the table to prevent auto-wrapping, which can break a function declaration line in weird places. So what's better: a flat listing or a table? Is there a third option? Generating reference docs via Doxygen (like ProgramOptions) probably isn't a viable solution since there's a lot of metaprogramming and atypical class construction going on in the BGL. Second, all of the reference docs for graph classes cite their associated types via the graph_traits and property_map templates. For most of these types, this strikes me as superfluous at best and slightly disingenuous at worst. Traits classes are only required in a generic context, not when working with a concrete type. If your graph class defines a nested type, vertex_iterator, why not use it directly? I feel that the reference documentation for data structures would be better served by focusing on the specifics of the data structure, not its generic interfaces. That's what the concepts are for. Thoughts? Andrew Sutton andrew.n.sutton(a)gmail.com

2 1

[date_time, Boost 1.40.0]
by Christoph 03 Sep '09

03 Sep '09

including boost/date_time/posix_time/posix_time.hpp or boost/date_time/gregorian/gregorian.hpp gives lots of warning for the following line(s): (boost/date_time/gregorian/conversion.hpp; posix_time, tooo) line 44 std::tm datetm = {}; // zero initialization is needed for extension members, like tm_zone I admit I don't understand the comment. Is it possible to fix that (correctly) such that including the header does not produce like 20 warnings in each .cpp file including the header? (I am using linux running gcc 4.1.2) Best regards Christoph

4 5

[serialization] using boost::serialization::collection_size_type and backwards compatibility
by joaquin＠tid.es 03 Sep '09

03 Sep '09

An observant colleague has noticed that Boost.MultiIndex serialization uses std::size_type instead of the adviced boost::serialization::collection_size_type: https://svn.boost.org/trac/boost/ticket/3365 My question is: if I just change std::size_type with boost::serialization::collection_size_type in Boost.MultiIndex serialization code, will backwards compatibility be preserved, i.e. will users be able to load archives saved with the old std::size_type variant? If not, what's the suggested way to handle this issue? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

compile-time for-loop
by klaus triendl 03 Sep '09

03 Sep '09

I wonder whether a compile-time for-loop is useful enough so that it would get included in the mpl library; it's very similar to what fold does but it can be used for computations with types other than sequence containers. The loop construct takes a start value, a loop condition and a function calculating the next start value for the next loop recursion and additionally a state together with a binary operation serving as loop body: namespace boost { namespace mpl { template< typename Start, typename UnaryLoopTest, typename BinaryNext , typename State, typename BinaryOp > struct for_: eval_if< // loop as long as the loop condition yields true typename apply< UnaryLoopTest, typename Start::type >::type, // next loop iteration: recursive call for_< // calculate next loop value typename apply< BinaryNext, State, typename Start::type >::type, // pass on UnaryLoopTest and pass on BinaryNext UnaryLoopTest, BinaryNext, // calculate next state typename apply< BinaryOp, State, typename Start::type >::type, // pass on BinaryOp BinaryOp >, // loop termination if loop condition yields false State > {}; } } // That's an example how to use the for-loop: using namespace boost; template<typename T, T N> struct cross_total: mpl::for_< // start mpl::integral_c<T, N>, // loop condition mpl::not_equal_to<mpl::_1, mpl::integral_c<T, 0> >, // calculate next value mpl::divides<mpl::_2, mpl::int_<10> >, // state = current cross sum of already iterated digits mpl::int_<0>, // binary function is loop body: crosstotal += digit mpl::plus< mpl::_1, mpl::modulus<mpl::_2, mpl::int_<10> > > >::type {}; </code> More useful may be to calculate a number's digits for any base, which can be used to calculate the required maximum storage size for a type (I know that there's std::numeric_limits<> but this one would be more general). Klaus Triendl

4 6

[Polygon] performance
by Simonson, Lucanus J 03 Sep '09

03 Sep '09

Performance has become a critical aspect of this review with the revelation that Barend claims significant performance advantage with his recent implementation. I would like to address this issue directly and, unfortunately, I must do so by addressing Barend's implementation and comparing it to my own, which I would have preferred to avoid. I realize that this comparison of the two algorithms may appear confrontational. My intention is to focus on technical issues to allow people to understand Barend's performance claims in the context of what the two algorithms have in common and how they differ. My understanding of Barend's algorithm is based solely on what he has told me, and he refused to tell me enough to allow me to implement it myself, so if I am in error in my description of it I trust he will promptly correct me. First, I do not believe that Barend's implementation is numerically robust when instantiated with float or double. Successfully passing tests is not proof that his algorithm will not generate self intersecting polygons at its output. Specifically, it is my understanding that his algorithm snaps intersection points to the floating point grid at the end of computation when he writes out output polygons. This means that edges may move laterally a distance dependent on the exponent of the floating point value of the result. In floating point coordinates a vertex may lie arbitrarily close to a nearby edge. Even a very small lateral movement of that edge due to loss of precision in the floating point representation has the potential to cross a nearby vertex and interduce self intersection in the output polygons. Since "simple polygons" is a common precondition to many algorithms (including Barend's own) it is simply unacceptable for there to be any chance of this post condition not being satisfied. Note that infinite precision floating point calculations don't solve this problem if you convert the output to regular floating point at some later stage, which is the common way the algorithm's output would be consumed. Second, Barend has stated that his algorithm does the same thing as mine. This is simply not true. Barend's algorithm imposes quite a few preconditions on its inputs (non-self intersecting being just one example) while mine imposes none. The two arguments of a boolean operation in my library may be any number of intersecting and overlapping polygons, Barend requires that all polygons be simple and non-overlapping. My algorithm accepts a broader range of inputs, which makes it more general and more powerful than Barend's algorithm and a better algorithm to use in a generic interface where preconditions become concept requirements for input geometry data. Furthermore, my algorithm has more output modes such as trapezoidization and keyholing as well as the flexibility to perform n-layer operations such as connectivity extraction and map overlay. Barend's algorithm does not. Comparing Barend's intersection algorithm to my own is not an apples to apples comparision, it is an apple to fruit basket which happens to contain an apple comparision. For these two reasons I think we should take Barend's performance claims with a grain of salt. When compared to other libraries that are known to be numerically robust (GPC, CGAL, Geos) my library is sometimes slower, sometimes faster in Barend's own benchmarking. Only Barend's algorithm is always faster in his benchmarking. However, if Barend's library has the potential to produce self intersecting output it is not even in the same class as these others. My benchmark data can be reproduced using the forcgal.cpp file in the sandbox/gtl directory. I provided it when Andreas asked. I admit that my algorithm could be faster. For the benchmarks I performed I estimated it could be up to 10X faster. For Barend's benchmarks with many pointed star polygons which result in O(n^2) pathological performance of my admittedly suboptimal line segment intersection algorithm that number might be higher sill. I would prefer that the focus of the review be the concept interfaces (function declarations) and how the typesystem is implemented so that we can decide whether it is a good model for a generic geometry API. Changes to eg. the line intersection algorithm or internals of polygon_set_data class can be made without breaking code that depends on the library API. If someone implements a true drop in replacement for my polygon intersection algorithm (or just for line segment intersection) and licenses it under the boost license we can drop it in if it is faster and all any user should notice is that the library is faster in a new release of boost. I don't think there are any decisions I made in the design or implementation of the concept type system or library interfaces that prevent or even make difficult such a change to its implementation details. Overall, I don't think we should view this review as an either or Boost.Polygon now or GGL later decision. There is no reason both libraries cannot be accepted in due time. Barend has made quite a bit a progress since boostcon and I am genuinely happy for him for what he has achieved. Thanks, Luke

3 2

Formal Review of Boost.Polygon extended one more week: until September 9, 2009
by Fernando Cacciola 02 Sep '09

02 Sep '09

Dear developers, The review of Boost.Polygon was initially scheduled to end today. However, the discussions are in their best moment only now so the review period was extended by one week, until September 9, 2009 (that is next Wednesday). Best Fernando Cacciola Review Manager

1 0

[pool] patch to make pool support zero sized allocations.
by Steven Watanabe 02 Sep '09

02 Sep '09

AMDG The patch at https://svn.boost.org/trac/boost/attachment/ticket/386/pool.patch allows the pool classes to support zero sized allocation, by returning a null pointer. std::vector sometimes allocates a zero sized block, so this is necessary for pool_allocator. Returning a null pointer is the simplest solution and I'm that the standard allows an allocator to return the null pointer when asked for a block of zero elements. Okay to commit? In Christ, Steven Watanabe

1 1

Re: [boost] [mpl, units] rational and static_rational
by Matthias Schabel 02 Sep '09

02 Sep '09

> I am looking for a template library that can handle compile time > rationals, ideally with a similar interface to mpl::int_ and that > plays well with boost::rational (the dynamic type). > > First I found boost/mpl/math/rational_c.hpp but soon I realized that > it doesn't work with basic operations like mpl::plus, it doesn't even > simplify reducible fractions (i.e. 2/4 -> 1/2), in fact it looks like > it is just the storage of two (static) integers. Is this something > that will be developed in the future or am I using it in the wrong > way? > > Then I found boost::units::static_rational which is more promising, > because it simplifies fractions and works with mpl::plus, but it is > not integrated with boost::rational nor has an interface similar to > that of mpl metatypes. > > Is there a way of extending mpl::math::rational_c with the existing > libraries in boost, or a simple way to make > boost::units::static_rational have an interface similar to mpl and > also have a value type that returns it runtime boost::rational value? I certainly would have no objection to repackaging the static_rational type used in Boost.Units as an MPL type that plays nicely with Boost.Rational. My advice would be to put together a functional implementation and propose it for a mini-review. We could easily typedef units::static_rational -> mpl::rational_ in the units library. Matthias

1 0

[polygon] Overload resolution for operators fails
by Joachim Faulhaber 02 Sep '09

02 Sep '09

Hi Luke and polygonists, trying to set up some law based tests for boost::polygon I faced difficulties with the overload resolution of operators under msvc-9. This is the code sniplet where the problems occur: ----------------------------------------------------------- #include <boost/validate/laws/law.hpp> #include <boost/polygon/polygon.hpp> // Here I map a PolygonSet class to geometry_concepts according to // the docs: #include <boost/itl_xt/custom_polygon.hpp> namespace boost{namespace itl { template <typename Type> class PolygonCommutativity : public Law<PolygonCommutativity<Type>, LOKI_TYPELIST_2(Type,Type), LOKI_TYPELIST_2(Type,Type)> { // a o b == b o a . . . bool holds() { using namespace boost::polygon; using namespace boost::polygon::operators; Type value_a = this->template getInputValue<operand_a>(); Type value_b = this->template getInputValue<operand_b>(); Type left = value_a; left += value_b; // Compiler fails to find the appropriate overload // but // this works self_assignment_boolean_op<Type,Type,0>(left, value_b); // and also this works boost::polygon::operators::operator+=<Type,Type>(left, value_b); // and this boost::polygon::operators::operator+=(left, value_b); . . . return equivalence(left, right); } }; ----------------------------------------------------------- moreover, if my custom PolygonSet conainer implements an operator += this operator is *silently* chosen by the compiler, so the wrong addition function is called! Contrary to the traditional understanding of a concept, that defines *requirements* for a parameter class it can use, we have to take care here, that the client class *does not* implement certain operations. I am afraid this is not a good thing. I hope this is fixable, may be the error is on my side but I can't see it yet. Regards Joachim

2 2

[property_tree] Still no support for space
by Preston A. Elder 02 Sep '09

02 Sep '09

I noticed property_tree just got updated in the SVN repository. As per my previous email, RapidXML was upgraded from 1.0 -> 1.13. All well and good. This did fix problems with whitespace handling in previous versions - or more correctly, it split the functionality so it was controlled by 2 different flags. However, in addition to this, the flags passed to RapidXML have changed. Specifically, now the flags parse_normalize_whitespace and parse_trim_whitespace are both passed to RapidXML. And there is no way to disable this. In fact, there is no way to adjust space parsing at all in property_tree. The reason this is of concern to me is this. There is no way to get this to work: <field> <field> or <field>] <field> or <field> </field> None of which will output the space in the result. RapidXML doesn't parse an XSL file, nor does it understand xml:space. So even the following will not work: <field xml:space="preserve"> </field> or <field xml:space="preserve">] </field> In short, could you PLEASE adjust the RapidXML (which is still the default XML parser) options not to mangle the living heck out of all spaces, or provide the ability for the user to specify the behavior they want (like you do with comments). I should also mention that RapidXML defaults both parse_normalize_whitespace and parse_trim_whitespace to off. I did my own testing, adjusting the flags to RapidXML. If I leave parse_normalize_whitespace ON, but turning off parse_trim_whitespace, the <field> </field> and <field>] </field> examples above work. No adjustment either of these settings will make <field> </field> work. PreZ

2 1

boost::regex Library crashes in MSVC8.0
by Naren Ramakrishnan 02 Sep '09

02 Sep '09

Hi, I am Boost novice and am trying to build a sample application from boost examples. The following is the environment details OS: Winxp sp2. Boost version : 1.40.0 Compiler / IDE : MSVC8.0/ Visual Studio 2005 I built the boost libraries using the above compiler using the bjam.exe tool and installed boost using the same tool(bjam.exe install). When I run the program(given below) by linking against libboost_regex-vc80-mt-1_39.lib with the following define flags(/D BOOST_REGEX_MATCH_EXTRA /D BOOST_REGEX_NO_LIB), I get a crash with the following message Unhandled exception at 0x00401e73 in BOOST TEST.exe: 0xC0000005: Access violation reading location 0x6c707849. Stack Trace is > BOOST TEST.exe!std::vector<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > > >::~vector<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > > >() Line 1088 C++ BOOST TEST.exe!std::vector<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > > >::_Destroy(boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > * _First=0x00383888, boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > * _Last=0x78138cd9) Line 1083 + 0x1d bytes C++ BOOST TEST.exe!std::vector<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > > >::~vector<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > > >() Line 1096 C++ BOOST TEST.exe!std::vector<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > >,std::allocator<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > > >::_Destroy(boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > * _First=0x00387c80, boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > * _Last=0x00387cbc) Line 1083 + 0x1d bytes C++ BOOST TEST.exe!boost::match_results<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> >,std::allocator<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > > >::~match_results<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> >,std::allocator<boost::sub_match<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char> > > > >() Line 81 + 0x83 bytes C++ BOOST TEST.exe!print_captures(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & regx={...}, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & text={...}) Line 44 + 0x22 bytes C++ BOOST TEST.exe!main(int __formal=, int __formal=) Line 48 + 0x3c bytes C++ BOOST TEST.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C The program is #include "stdafx.h" #include <boost/regex.hpp> #include <iostream> using namespace boost; void print_captures(const std::string& regx, const std::string& text) { boost::regex e(regx); smatch what,w; std::cout << "Expression: \"" << regx.c_str() << "\"\n"; std::cout << "Text: \"" << text.c_str() << "\"\n"; if(boost::regex_search(text, what, e, boost::match_perl)) { unsigned i, j; std::cout << "** Match found **\n Sub-Expressions:\n"; for(i = 0; i < what.size(); ++i) std::cout << " $" << i << " = \"" << what[i].str().c_str() << "\"\n"; std::cout << " Captures:\n"; for(i = 0; i < what.size(); ++i) { std::cout << " $" << i << " = {"; j=0; for(j = 0; j < what.captures(i).size(); ++j) { if(j) std::cout << ", "; else std::cout << " "; std::cout << "\"" << what.captures(i)[j].str().c_str() << "\""; } std::cout << " }\n"; } } else { std::cout << "** No Match found **\n"; } } int main(int , char* []) { print_captures("Microsoft ", " Microsoft Internet Explorer"); print_captures("(.*)bar|(.*)bah", "abcbar"); print_captures("(.*)bar|(.*)bah", "abcbah"); print_captures("^(?:(\\w+)|(?>\\W+))*$", "now is the time for all good men to come to the aid of the party"); return 0; } However when I compile and run this program against boost libraries available in sourceforge under boost-binaries, it works fine. I am sure I am missing something. Could you please help me out Thanks Naren

3 4

Boost.FileSystem talk from BoostCon now available
by Marshall Clow 01 Sep '09

01 Sep '09

at <http://blip.tv/file/2541291> More to come as I dig myself out..... -- Marshall

1 0

[serialization] working around the pointer_conflict exception?
by T. Farago 01 Sep '09

01 Sep '09

I have implemented the serialise library of BOOST to my own classes. Using a single entry point it recursively goes through every member and saves the values. Of course initial implementation yielded the pointer_conflict expression as for example while going through objects A,B,C object A may have a pointer to B, and only afterwards is B actually saved. I tried - and thought - to fix this by using a two-phased approach. First I save all the actual objects from the entry point, secondly only the pointers. eg save_objects = true; ar & my_object; save_objects = false; ar & my_objects; and inside every class: class A { public: int a; int *b; serialise() { if (save_objects) { ar & a; } else { ar & b; } } }; This seemed sound but only during debugging did I realise that the second run of the serialiser doesn't do anything since my_object is already saved. So this won't work. Does anyone have better ideas on solving this problem, or has encountered and already solved this issue? -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

2 2

Boost Polygon library Review
by Kai Benndorf 01 Sep '09

01 Sep '09

Dear developers, we are currently evaluating the boost polygon library as a possible replacement for our currently used package for polygon boolean operations. Because the review process is soon at an end i want to inform you of our experiences so far. For short, i vote for inclusion of the polygon lib into boost. We are evaluating it in the scope of an analysis tool out of the EDA field. One task in this tool is to determine overlays of copper planes on a pcb. For this we need the plane intersection functionality. We have integrated the boost polygon lib currently to use it in parallel to our old library. Up to now we have found no errors in the calculated plane intersections, and there are some quite complicated planes, with complicate holes on the test pcb. This is very promising and the results seem to be reliable. We used the library on Windows XP, MSVC 2008, only. No compilation problems occured. Double vs. integer coordinates. Our planes are described with double coordinates in mm. We convert them for the boost polygon lib to integer by multiplying them with a constant factor. A first try with an factor of 1e5 leaded to an error (overflow?). With a factor of 1e4 this error vanished. Our first approach was to use the polygon and polygon with hole classes provided by the library and copy our coordinates into them. It works, but the creation of the objects with the set( itBegin, itEnd) functions was really slow, especially for copying the holes into the polygon. Our current approach is with some own intermediate polygon and polygon with holes classes, which allocates the necessary memory on creation. This is a lot faster and is really usable. A third and still better approach would be to use the same polygon classes as in the rest of our application, but i postponed this for now. The performance seems to be slower than our old library, but this is not really evaluated yet, there can e.g. still be conversion penalties. The documentation was sufficient enough to integrate the library in our application, but surely can be better. Because i'm not experienced in such an extensive template usage as it is done in the polygon lib, i omit comments about the design of the library. But at least it proved, that it can really be used to work reliable on external polygon objects. Best regards Kai Benndorf

2 1

windows timeout implementation
by Gennadiy Rozental 01 Sep '09

01 Sep '09

Hi, I have windows timeout support implemented for boost::execution monitor. It requires multithreading and thus introduces additional dependencies. I am thinking of making it available with compile time flag. Any comments/suggestions are welcome. Gennadiy

4 4

[GSoC] Boost.Python py3k support project final report
by Haoyu Bai 01 Sep '09

01 Sep '09

Hi, As GSoC is officially finished, this is the final report of the Boost.Python py3k(Python 3) support project. The goal of this project is to provide seamless support for Python 2 and 3 in Boost.Python. So extension modules using Boost.Python can be easily migrated to Python 3. The SVN branch is located at: https://svn.boost.org/svn/boost/sandbox-branches/bhy/py3k/ Status ===== Currently, all the BPL test cases passed when running under Python 3, and there are almost no change for most of the test cases. To support the Python 3 unicode string, some of the default converts between PyString and C/C++ strings are changed to convert between PyUnicode and C/C++ strings. Support for py3k in Boost.Build is done. Also, a piece of document is written in the "News" part of BPL document. API Changes ========== There are some minor API changes: 1) Introduced object.contains where x.contains(y) is equivalent to Python code y in x. Now dict.has_key is just a wrapper of object.contains. 2) When building against Python 3, str.decode will be removed. 3) When building against Python 3, the original signature of list.sort, which is: void sort(object_cref cmpfunc); will change to: void sort(args_proxy const &args, kwds_proxy const &kwds); This is because in Python 3 list.sort requires all its arguments be keyword argument. So you should call it like this: x.sort(*tuple(), **dict(make_tuple(make_tuple("reverse", true)))); // This is equivalent to the Python call x.sort(reverse=true) 4) When building Boost.Python against Python older than 2.6, the following macros will be defined in Boost.Python header: # define Py_TYPE(o) (((PyObject*)(o))->ob_type) # define Py_REFCNT(o) (((PyObject*)(o))->ob_refcnt) # define Py_SIZE(o) (((PyVarObject*)(o))->ob_size) These are macros defined in Python >=2.6 header. We defined for Python < 2.6 so when you are using Boost.Python, these macros will be always available. Please refer to PEP 3123 (http://www.python.org/dev/peps/pep-3123/) for details about these macro. Building and Testing =============== To build Boost.Python with Python 3, first write your user-config.jam contains these line: using python : 2.6 ; using python : 3.2 ; where the "2.6" and "3.2" should be replaced by the actual version of Python 2 and Python 3 on your system, respectively. Then call "bjam", it will build out a "libboost_python.so" and a "libboost_python3.so". The latter one is the Boost.Python library built against Python 3. To run test cases against Python 3, what you need to do is to switch into the libs/python/test, then run: bjam python=3.2 It will automatically call the "2to3" tool to convert the Python source code in test case to Python 3 syntax. So we only need to maintain the test cases in Python 2. Further Works =========== I'm going to merge the py3k branch back to trunk. After the merge, more tests can be done to check is there any regression, also some people may want to start to use it to make your projects run on Python 3. Then I can get some bug report and feedback, thus more improvement is expected. Thanks! -- Haoyu BAI School of Computing, National University of Singapore.

2 1