- Boost - lists.preview.boost.org

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