- Boost - lists.preview.boost.org

policy on compiler warnings?
by Kenny Riddile 21 Jun '09

21 Jun '09

Does Boost have any documented policy on compiler warnings? I, like a lot of people, use warning level 4 when compiling with MSVC. I also usually turn on warnings as errors, but I cannot easily do that since many Boost libraries emit warnings at warning level 4 under MSVC9. I realize that warnings aren't really standardized across compilers, but I would still expect a project that touts itself as "...one of the most highly regarded and expertly designed C++ library projects in the world." to strive for zero warnings under a commonly used setting on one of its official test compilers. I have created the following tickets regarding warnings that are currently causing me trouble: https://svn.boost.org/trac/boost/ticket/3193 https://svn.boost.org/trac/boost/ticket/3194 https://svn.boost.org/trac/boost/ticket/3195 https://svn.boost.org/trac/boost/ticket/3196 https://svn.boost.org/trac/boost/ticket/3197 Thanks, Kenny Riddile

1 1

[config] missing include for FreeBSD
by k-oli＠gmx.de 20 Jun '09

20 Jun '09

Hi, boost/config/platform/bsd.hpp misses include sys/param.h. Without this header __FreeBSD_version can not be evaluated. regards, Oliver

1 0

convert boost::mpl::vector_c<int> into const int[]
by Peter Foelsche 20 Jun '09

20 Jun '09

Is there any way to convert a boost::mpl::vector_c<int> into a const int[] without using boost::mpl::for_each?

3 2

[task] Minor issues
by Chard 19 Jun '09

19 Jun '09

I've been trying out the task library from the vault and have found a few issues. The code does not compile with MSVC 7.1; this appears to be a compiler non-conforming issue rather than code error: The contained impl_pool class inside detail::worker requires access to the static pool class, but even though the detail::worker class is a friend, VC7 doesn't allow impl_pool access. Adding: template< typename Pool > friend class detail::worker::impl_pool; to the class in static_pool.hpp gets around this. <> I believe there is another error in the task config.hpp file; it has the line: # if defined(BOOST_TASK_DYN_DLL) || defined(BOOST_ALL_DYN_LINK) I believe BOOST_TASK_DYN_DLL should be BOOST_TASK_DYN_LINK, following the guide from the main boost config.

2 1

[polygon] GTL name change and pre-review issues
by Simonson, Lucanus J 19 Jun '09

19 Jun '09

I am changing the name of my library from GTL (Geometry Template Library) to boost::polygon and narrowing the scope from "computational geometry" to "polygon manipulation". This scope precisely describes the current scope of what is implemented. It also clarifies the position of the library relative to similar proposals. I have already moved the code into boost::polygon namespace, added dependency on boost::enable_if and gotten the unit tests compiling and passing in windows with the new namespace and dependency. I wanted to ask about the gtl_yes and gtl_no types I use for metaprogramming, defined thus: struct gtl_no { static const bool value = false; }; struct gtl_yes { typedef gtl_yes type; static const bool value = true; }; I need to define type as gtl_yes in gtl_yes and leave it undefined in gtl_no to enable early SFINAE to work around an EDG compiler bug: template <typename geometry_type_1, typename coordinate_type_1> typename enable_if< typename gtl_and< typename is_mutable_polygon_90_set_type<geometry_type_1> #ifdef __ICC ::type #endif ::type, typename gtl_same_type<typename geometry_concept<coordinate_type_1>::type, coordinate_concept>::type> #ifdef __ICC ::type #endif ::type, geometry_type_1>::type operator-(const geometry_type_1& lvalue, coordinate_type_1 rvalue) { geometry_type_1 retval(lvalue); retval -= rvalue; return retval; } Here I am short circuiting template instantiation in the case that ICC (using EDG) is detected by calling the gtl_yes/gtl_no metafunction. This would be a syntax error in MSVC, of course. I need to do this for arithemetic operators because EDG incorrectly tries to match them to operators between pointer and unnamed enum type values in the stl and throws a syntax error when I refer to the unnamed enum type in the declaration of the operator. By SFINAEing out early I can work around this bug, which is fixed in the latest EDG versions, but I need to support older versions as well. Is it acceptable to continue to use my own definitions for true_type/false_type, or does someone have a suggestion for a different workaround that will allow me to replace gtl_yes/gtl_no with boost::true_type, boost::false_type? By the way, complete documentation for my library is now available at https://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm Feedback on the documentation before the formal review will help me get ready for the review. I'll be checking review ready code into the sandbox later today along with unit tests. If someone can point me to setup my unit test source file to work with the boost unit testing system I'd greatly appreciate it. Right now it just uses returning an error code to indicate test failure, and it is all or nothing in that sense. Regards, Luke

1 0

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

Boost.Bloom_filter now in Sandbox (WAS Re: Interest in a Bloom Filter?)
by Dean Michael Berris 19 Jun '09

19 Jun '09

On Mon, Jun 8, 2009 at 2:55 PM, Dean Michael Berris<mikhailberis(a)gmail.com> wrote: > On Mon, Jun 8, 2009 at 2:47 PM, Joaquin M Lopez Munoz<joaquin(a)tid.es> wrote: [snip] > > Thanks for your insights! I'll make the changes and then maybe put it > in the sandbox along with the documentation that I'll be working on. > The implementation is now available in Boost's Sandbox. You can check out the implementation along with the documentation via: svn co https://svn.boost.org/svn/boost/sandbox/bloom_filter/trunk/ Can someone please add this to the Libraries Under Construction page? I'd also like to request to add this to the formal review queue (if this qualifies for a fast track review, that would also be an option I'm open to). Thanks in advance, and I hope this helps. -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

9 33

[boost::noncopyable] compiler warnings with the -Weffc++ flags
by Anand Lakshminath 19 Jun '09

19 Jun '09

Hi, Deriving from the boost::noncopyable class generates warnings when I compile with the -Weffc++ (effective C++) flags. There are two types of warnings: 1) Non-virtual destructor warning (base class 'class boost::noncopyable_::noncopyable' has a non-virtual destructor). Here's a testcase: #include <boost/noncopyable.hpp> #include <iostream> namespace { class DontTreadOnMe : private boost::noncopyable { public: DontTreadOnMe() { std::cout << "defanged!" << std::endl; } }; // DontTreadOnMe } // unnamed namespace main() { DontTreadOnMe object1; } g++ -I/vobs/3rdparty/BOOST/boost_1_38_0/boost_inc -Weffc++ main.cpp main.cpp:10: warning: base class 'class boost::noncopyable_::noncopyable' has a non-virtual destructor 2) I have disabled the copy constructor/assignment operator in a class that has pointer data members by deriving from boost::noncopyable. However, the compiler generates the following warning: warning: 'class<unnamed>::DontTreadOnMe' has pointer data members main.cpp:10: warning: but does not override '<unnamed>::DontTreadOnMe(const <unnamed>::DontTreadOnMe&)' This kind of forces me to explicitly override the copy constructor and assignment operator instead of deriving from noncopyable. Here's the full test case: #include <boost/noncopyable.hpp> #include <iostream> namespace { class DontTreadOnMe : private boost::noncopyable { public: DontTreadOnMe() { std::cout << "defanged!" << std::endl; } private: char* buf; }; // DontTreadOnMe } // unnamed namespace main() { DontTreadOnMe object1; } g++ -I/vobs/3rdparty/BOOST/boost_1_38_0/boost_inc -Weffc++ main.cpp main.cpp:10: warning: base class 'class boost::noncopyable_::noncopyable' has a non-virtual destructor main.cpp:10: warning: 'class<unnamed>::DontTreadOnMe' has pointer data members main.cpp:10: warning: but does not override '<unnamed>::DontTreadOnMe(const <unnamed>::DontTreadOnMe&)' main.cpp:10: warning: or 'operator=(const <unnamed>::DontTreadOnMe&)' Is there a workaround and/or fix? I am using gcc 4.0.1. Thanks, Anand

5 11

Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool and boost::fast_pool
by Christian Schladetsch 19 Jun '09

19 Jun '09

Hello, I ran the following test http://tinyurl.com/l89llq This compares std::allocator, boost::fast_pool_allocator, boost::pool_allocator and monotonic::allocator. The only test in which monotonic allocation fails to perform faster than the other schemes is thrash_pool_sort_list_int against fast_pool. The reason for this is that fast_pool effectively stores a pre-generated array of correctly-aligned chunks, so allocation against this is a pointer increment. Fast pool can do this, because it stores different pools for different-sized blocks. Rather, the monotonic allocator uses a single buffer for all allocations, so it has to align each time. There is an optimisation I can introduce between a monotonic::allocator<T> and the underlying storage that can improve performance slightly for this case. The downside for fast_pool is that the user has to keep track of each different-sized chunk that can possiblly be used, and it doesn't differentiate on type. From the documentation: "Since the size of T is used to determine the type of the underlying Pool, each allocator for different types of the same size will share the same underlying pool. The tag class prevents pools from being shared between pool_allocator and fast_pool_allocator. For example, on a system where sizeof(int) == sizeof(void *), pool_allocator<int> and pool_allocator<void *> will both allocate/deallocate from/to the same pool." This is problematic for cases where a given allocator is rebound to a different type, as happens for the node-based containers. I am unsure what the best practise is here, or if boost::pool and boost::fast_pool simply leak in this case. You will also not that fast_pool is very slow for thrash_pool_sort, which sorts different-sized vectors. Here, the same mechanism that made it %10-%20 faster than monotonic using lists makes it many times slower when using vectors. In the following tables, the first row is the maximum number of elements in the relevant container; all internal columns are in seconds. Results for MSVC /O2. thrash_pool count fast_p pool std mono local fp/mono pool/mono 10 0.015 0.019 0.02 0.005 0.005 300% 380% 210 0.035 0.037 0.038 0.01 0.009 350% 370% 410 0.051 0.055 0.04 0.013 0.013 392.3% 423.1% 610 0.069 0.072 0.046 0.017 0.017 405.9% 423.5% 810 0.088 0.093 0.048 0.021 0.022 419% 442.9% 1010 0.105 0.111 0.053 0.026 0.028 403.8% 426.9% 1210 0.125 0.138 0.06 0.031 0.03 403.2% 445.2% 1410 0.142 0.143 0.061 0.034 0.033 417.6% 420.6% 1610 0.164 0.162 0.069 0.038 0.038 431.6% 426.3% 1810 0.179 0.184 0.072 0.043 0.042 416.3% 427.9% thrash_pool_iter count fast_p pool std mono local fp/mono pool/mono 10 0.027 0.032 0.032 0.012 0.011 225% 266.7% 210 0.152 0.146 0.118 0.102 0.101 149% 143.1% 410 0.27 0.263 0.199 0.191 0.189 141.4% 137.7% 610 0.4 0.372 0.286 0.283 0.284 141.3% 131.4% 810 0.509 0.487 0.376 0.372 0.372 136.8% 130.9% 1010 0.64 0.598 0.474 0.474 0.464 135% 126.2% 1210 0.765 0.721 0.579 0.563 0.592 135.9% 128.1% 1410 0.895 0.841 0.632 0.662 0.652 135.2% 127% 1610 0.991 0.923 0.701 0.714 0.759 138.8% 129.3% 1810 1.185 1.096 0.793 0.91 0.842 130.2% 120.4% thrash_pool_sort count fast_p pool std mono local fp/mono pool/mono 10 0.01 0.002 0.002 0.001 0.001 1000% 200% 110 0.091 0.011 0.011 0.008 0.009 1138% 137.5% 210 0.233 0.023 0.02 0.017 0.016 1371% 135.3% 310 0.495 0.034 0.026 0.025 0.025 1980% 136% 410 1.347 0.044 0.036 0.035 0.034 3849% 125.7% 510 1.411 0.058 0.045 0.042 0.042 3360% 138.1% 610 2.928 0.067 0.055 0.052 0.053 5631% 128.8% 710 2.54 0.078 0.064 0.065 0.061 3908% 120% 810 6.175 0.089 0.073 0.07 0.07 8821% 127.1% 910 3.976 0.104 0.081 0.082 0.08 4849% 126.8% thrash_pool_sort_list_int count fast_p pool std mono local fp/mono pool/mono 10 0.006 0.011 0.011 0.003 0.004 200% 366.7% 210 0.057 0.087 0.088 0.06 0.059 95% 145% 410 0.102 0.214 0.169 0.135 0.125 75.56% 158.5% 610 0.156 0.367 0.254 0.199 0.196 78.39% 184.4% 810 0.211 0.588 0.346 0.26 0.261 81.15% 226.2% 1010 0.269 0.837 0.459 0.351 0.35 76.64% 238.5% 1210 0.347 1.16 0.547 0.441 0.431 78.68% 263% 1410 0.406 1.504 0.632 0.54 0.511 75.19% 278.5% 1610 0.481 1.882 0.728 0.583 0.587 82.5% 322.8% 1810 0.559 2.32 0.817 0.671 0.674 83.31% 345.8% thrash_pool_map_list_unaligned count fast_p pool std mono local fp/mono pool/mono 10 0.002 0.003 0.004 0.001 0.001 200% 300% 210 0.033 0.083 0.079 0.029 0.029 113.8% 286.2% 410 0.067 0.214 0.164 0.058 0.061 115.5% 369% 610 0.102 0.404 0.246 0.091 0.092 112.1% 444% 810 0.139 0.646 0.338 0.122 0.126 113.9% 529.5% 1010 0.174 0.936 0.415 0.155 0.16 112.3% 603.9% 1210 0.219 1.271 0.51 0.19 0.197 115.3% 668.9% 1410 0.253 1.675 0.594 0.23 0.237 110% 728.3% 1610 0.297 2.144 0.678 0.273 0.274 108.8% 785.3% 1810 0.339 2.692 0.874 0.402 0.313 84.33% 669.7% Results for GCC -O2 thrash_pool count fast_p pool std mono local fp/mono pool/mono 10 0 0.01 0 0.01 0 0% 100% 210 0.01 0.01 0.01 0 0 inf% inf% 410 0.01 0 0.01 0.01 0 100% 0% 610 0.01 0.01 0.01 0 0 inf% inf% 810 0.01 0 0.01 0.01 0 100% 0% 1010 0 0.01 0 0 0.01 nan% inf% 1210 0.01 0.01 0.01 0 0 inf% inf% 1410 0.01 0 0.01 0 0.01 inf% nan% 1610 0 0.01 0.01 0 0 nan% inf% 1810 0 0.01 0 0 0.01 nan% inf% thrash_pool_iter count fast_p pool std mono local fp/mono pool/mono 10 0.01 0.01 0 0.01 0 100% 100% 210 0.05 0.06 0.02 0.02 0.02 250% 300% 410 0.12 0.1 0.04 0.03 0.03 400% 333.3% 610 0.16 0.15 0.05 0.05 0.04 320% 300% 810 0.2 0.21 0.06 0.06 0.07 333.3% 350% 1010 0.25 0.25 0.07 0.08 0.08 312.5% 312.5% 1210 0.29 0.31 0.08 0.08 0.09 362.5% 387.5% 1410 0.33 0.35 0.1 0.08 0.1 412.5% 437.5% 1610 0.38 0.37 0.11 0.12 0.12 316.7% 308.3% 1810 0.43 0.45 0.12 0.13 0.13 330.8% 346.2% thrash_pool_sort count fast_p pool std mono local fp/mono pool/mono 10 0.01 0.01 0 0 0 inf% inf% 110 0.06 0.01 0.01 0.01 0.01 600% 100% 210 0.19 0.02 0.02 0.02 0.01 950% 100% 310 0.47 0.02 0.02 0.02 0.02 2350% 100% 410 0.69 0.04 0.04 0.03 0.02 2300% 133.3% 510 1.99 0.05 0.04 0.03 0.04 6633% 166.7% 610 1.65 0.06 0.04 0.04 0.04 4125% 150% 710 4.73 0.07 0.05 0.04 0.05 1.182e+04% 175% 810 2.28 0.07 0.07 0.06 0.06 3800% 116.7% 910 4.29 0.09 0.05 0.08 0.06 5362% 112.5% thrash_pool_sort_list_int count fast_p pool std mono local fp/mono pool/mono 10 0 0.01 0 0 0 nan% inf% 210 0.03 0.05 0.04 0.04 0.03 75% 125% 410 0.07 0.15 0.1 0.08 0.06 87.5% 187.5% 610 0.1 0.26 0.12 0.11 0.12 90.91% 236.4% 810 0.13 0.39 0.19 0.18 0.14 72.22% 216.7% 1010 0.17 0.57 0.24 0.19 0.2 89.47% 300% 1210 0.24 0.74 0.29 0.23 0.24 104.3% 321.7% 1410 0.26 0.98 0.36 0.26 0.28 100% 376.9% 1610 0.27 1.21 0.37 0.3 0.33 90% 403.3% 1810 0.35 1.51 0.43 0.35 0.37 100% 431.4% thrash_pool_map_list_unaligned count fast_p pool std mono local fp/mono pool/mono 10 0 0 0 0 0 nan% nan% 210 0.02 0.05 0.03 0.02 0.02 100% 250% 410 0.02 0.11 0.06 0.04 0.04 50% 275% 610 0.06 0.19 0.11 0.07 0.07 85.71% 271.4% 810 0.06 0.33 0.13 0.09 0.08 66.67% 366.7% 1010 0.09 0.51 0.17 0.11 0.11 81.82% 463.6% 1210 0.12 0.65 0.21 0.13 0.14 92.31% 500% 1410 0.15 0.93 0.25 0.14 0.14 107.1% 664.3% 1610 0.17 1.11 0.27 0.19 0.15 89.47% 584.2% 1810 0.18 1.35 0.33 0.21 0.21 85.71% 642.9% Regards, Christian

1 1

From Concept class to type traits
by joel 19 Jun '09

19 Jun '09

Is there any deep explanation on how the concept_check class from Boost:/Concept works ? I'm trying to see how to turn a concept into a traits but all my attempt are failing miserably and I think that's because I don't get how the concept check work in itself. Regards -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

5 6

Fwd: bug fix in boost/libs/python/pyste/src/Pyste/declarations.py
by YuQian Zhou (周宇前) 19 Jun '09

19 Jun '09

Hi, I was unable to reach Dave, and https://svn.boost.org/trac/boost/newticket doesn't work for me. ("Secure Connection Failed"). So I'm posting here, can anyone take a look this? thanks. ---------- Forwarded message ---------- From: YuQian Zhou (周宇前) <zhou(a)google.com> Date: 2009/6/15 Subject: Fwd: bug fix in boost/libs/python/pyste/src/Pyste/declarations.py To: dave(a)boost-consulting.com Hi Dave, Can you tell me where I should submit this change? Thanks. ---------- Forwarded message ---------- From: Bruno Oliveira <nicoddemus(a)gmail.com> Date: 2009/6/15 Subject: Re: bug fix in boost/libs/python/pyste/src/Pyste/declarations.py To: "YuQian Zhou (周宇前)" <zhou(a)google.com> Hi YuQian, Unfortunately I don't maintain Pyste anymore; I advise you to send this fix to the boost-python list, since I don't have commit privileges anymore (I think). Best Regards, On Mon, Jun 15, 2009 at 5:32 PM, YuQian Zhou (周宇前) <zhou(a)google.com> wrote: > > Hi Bruno, > > I found a bug in boost/libs/python/pyste/src/Pyste/declarations.py (I > tried the latest version (Version 1.39.0) from boost.org, it has the > same bug.) > > The bug is: when paring an anonymous struct, the name passed to a > Declaration object is None, then on > libs/python/pyste/src/Pyste/GCCXMLParser.py: line 57 > > def AddDecl(self, decl): > if decl.FullName() in self._names: > > The call to FullName() will concatenate name, line 53: > > return namespace + self.name > > TypeError: cannot concatenate 'str' and 'NoneType' objects > > I made a fix below, please let me know if it's correct, and you can > include in the release. > > Thanks. > > YuQian > > Below is a test file: > > $ cat test.h > > typedef int __jmp_buf; > > typedef struct > { > struct > { > __jmp_buf __cancel_jmp_buf; > int __mask_was_saved; > } __cancel_jmp_buf[1]; > void *__pad[4]; > } __pthread_unwind_buf_t __attribute__ ((__aligned__)); > > > here is the diff of libs/python/pyste/src/Pyste/declarations.py > > 16d15 > < _anonymous_name_counter = 0 > 33,36d31 > < global _anonymous_name_counter > < if name is None: > < name = 'anonymous_name_%s' % _anonymous_name_counter > < _anonymous_name_counter += 1

1 0

Request: boost deprecated tag
by Chard 18 Jun '09

18 Jun '09

Given that there is a current move to rationalize the bind placeholders, and potentially introduce deprecated definitions, would it worth introducing a boost deprecated marker that makes use of compiler support to notify the user that they are using such definitions? I recently recompiled a project with BOOST_FILESYSTEM_NO_DEPRECATED (for no particular reason, except perhaps for tr1 readiness) and I was surprised how many uses of the old native_file_string and boost::native tags were buried in the code-base. Personally, I think it would be useful to be notified (or nagged :-)) if I was using deprecated functionality; I don't examine every comment of every function, and after successful compilation/unit-test they are easily forgotten. I don't know the best, generic, way of achieving this, but a simple approach that should work with MSVC and gcc would be to have: #ifndef BOOST_NO_DEPRECATED_WARNINGS // Don't nag me, compiler # if [BUILDING_WITH_MSVC] # define BOOST_DEPRECATED __declspec(deprecated) # else if [BUILDING_WITH_GCC] # define BOOST_DEPRECATED __attribute__ ((deprecated)) # else if [BUILDING_WITH_acme] # define BOOST_DEPRECATED ... # end if #endif #ifndef BOOST_DEPRECATED // No compiler support, just a tag # define BOOST_DEPRECATED #end if Then usage is: BOOST_DEPRECATED void TheFunction(...); The intent here is clear, and uncluttered, but may not be flexible enough. For example, a compiler may use syntax that declares its deprecated tag after the definition (which gcc supports, and it is usually shown that way in the guidelines). In which case, I expect the whole definition would have to be wrapped up in the macro. Also, there may be a case for separating the deprecated tags for functions, variables, types, etc.. As an (untested) illustration: #ifndef BOOST_NO_DEPRECATED_WARNINGS # if [BUILDING_WITH_MSVC] # define BOOST_DEPRECATED_FUNCTION(_F_) __declspec(deprecated) _F_ # else if [BUILDING_WITH_GCC] # define BOOST_DEPRECATED_FUNCTION(_F_) _F_ __attribute__ ((deprecated)) # else if [BUILDING_WITH_acme] # define BOOST_DEPRECATED_FUNCTION(_F_) ... # define BOOST_DEPRECATED_VARIABLE(_V_) ... # define BOOST_DEPRECATED_TYPE(_T_) ... # end if #endif #ifndef BOOST_DEPRECATED_FUNCTION # define BOOST_DEPRECATED_FUNCTION(_F_) _F_ #end if #ifndef BOOST_DEPRECATED_VARIABLE // Some compilers may use different syntax for variables, if not, // use same as deprecated function tag # define BOOST_DEPRECATED_VARIABLE(_V_) BOOST_DEPRECATED_FUNCTION(_V_) #endif #ifndef BOOST_DEPRECATED_TYPE // As for variables.. # define BOOST_DEPRECATED_TYPE(_T_) BOOST_DEPRECATED_FUNCTION(_T_) #endif Usage example: class path { ... BOOST_DEPRECATED_FUNCTION(string_type native_file_string() const) { return file_string(); } ... }; This is noisier, and may be worse if parentheses/comma expansion work-arounds are required, but it's an example. Personally, I prefer the simple BOOST_DEPRECATED, but I don't have experience with other compilers to know if that would suffice. Even if no support is available, having a benign tag in the definition provides information at the least. Regards...

2 2

Boost Trac/Subversion upgrade this Friday
by Doug Gregor 18 Jun '09

18 Jun '09

The Boost Trac and Subversion repository will be offline for a few hours this Friday, June 19th, while we upgrade to a new version of Trac. Mailing lists will not be affected. Here is the approximate down-time: Date: Friday June 19, 2009 Time: - 11:00am-2:00pm Pacific US time - 12:00pm-3:00pm Mountain US time - 1:00pm-4:00pm Central US time - 2:00pm-5:00am Eastern US time - 6:00pm-9:00pm GMT Cheers, - Doug

2 1

Getting involved in Boost
by Anteru 18 Jun '09

18 Jun '09

Hi, I'm a Boost user since quite some time now (1.33 or so), however, I did not contribute a library to Boost, and I was also not too active on the news groups (a few posts so far, at most.) When I look at the review queue, I can see lots and lots of interesting libraries waiting. So my question is: How can I, primary a Boost user, contribute to the community to help with getting new libraries into Boost? Primary, I'd be interested in PIMPL and the ThreadPool, possibly in AutoBuffer and Sorting. Is there some recommended way of reviewing a library "out-of-order" with no review manager, such that the review is easily identifiable and can be found when it comes to the real review? For me, it seems to be no problem to gather reviews of a library up-front. This could make it easier for a review manager to do his work, as he could simply start a formal review only after a certain number of reviews has been done. Side note: I couldn't find a recent review status on the website -- under Development, Submissions, the latest report is from 2008, while the one latest one I could find is from June 2009. However, it does not say what the current status of the UUID is -- did I miss some obvious page with the status of all libraries? Cheers, Anteru

2 1

some mpl programming task -- don't get this compiled
by Peter Foelsche 18 Jun '09

18 Jun '09

I'm still unclear about some fundamentals of the mpl library. Could somebody have a look at this source code? I'm playing around with this since quite a while. I'm trying to convert some information into an array of strings. I'm using boost::mpl::map instead of vector as I want to overwrite points in a two dimensional matrix. So in fact this is a map indexed by a long containing another map indexed by a long containing char. Two dimensional quadratic matrix of char. Thanks Peter

2 5

[date_time] [#1861] Change for the default duration format
by Andrey Semashev 17 Jun '09

17 Jun '09

Hi, There's a Boost.DateTime ticket: https://svn.boost.org/trac/boost/ticket/1861 The initial problem was that the default handling of the %H format specifier (passing it to strftime) played badly with time durations that could be longer than 24 hours. The resolution was to provide additional %O format specifier that does not have 24 hour restriction. However the original poster proposes to change the default format of time durations from %H:%M:%S%F to %O:%M:%S%F so that formatted durations are always allowed to be longer than 24 hours. I mostly agree with this change, however it is clearly a breaking change that can affect error checking in some cases. What do the community and the maintainer (Jeff?) in particular think about this?

4 15

Proposal: MapReduce library (single machine)
by Craig Henderson 17 Jun '09

17 Jun '09

MapReduce is a programming model from Google that is designed for scalable data processing. Google's implementation is for scalability over many thousands of commodity machines, but there is value in using the idiom on multi-core processors to partition processing to efficiently use the CPU available, and avoid the complexities of multi-threaded development. I have a implemented a MapReduce runtime library in C++ using Boost and would like to see if there is interest from you all to submit the library to Boost. I have preliminary documentation on my website at http://www.craighenderson.co.uk/mapreduce/ Regards -- Craig Craig Henderson <http://craighenderson.co.uk/> http://www.craighenderson.co.uk http://www.siteupdatenotification.com

6 11

Compilation error in boost::bind
by Zachary Turner 17 Jun '09

17 Jun '09

The documentation for __stdcall in MSVC says the following: On Itanium Processor Family (IPF) and x64 processors, __stdcall is accepted and ignored by the compiler. Because of this, the following fragment from <boost/bind/bind.hpp> fails when causes build errors for either of these platforms: #define BOOST_BIND_CC #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #ifdef BOOST_BIND_ENABLE_STDCALL #define BOOST_BIND_CC __stdcall #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #endif Since it ignores the __stdcall the second time around, all the templates are re-declared with cdecl causing duplicate symbol definition errors. This is confirmed on MSVC 9.0 but I assume it exists on all versions of MSVC. What is the best way to fix this? I don't know much about how to use the BOOST_WORKAROUND macros, but I have patched this in my own version of bind.hpp by changing the block inside the ifdef to the following: #if defined(BOOST_BIND_ENABLE_STDCALL) && !(defined(BOOST_MSVC) && defined(_WIN64)) #define BOOST_BIND_CC __stdcall #define BOOST_BIND_ST #include <boost/bind/bind_cc.hpp> #undef BOOST_BIND_CC #undef BOOST_BIND_ST #endif This doesn't handle the itanium case obviously but off the top of my head I'm not sure what MSVC #defines for itanium. What would be the most robust way to fix this?

3 2

[mpl] is there a or_seq like logical metafunction?
by vicente.botet 17 Jun '09

17 Jun '09

Hello, I needs calculate the mlp::or_ of a sequence of nullary logical metafunction. This seams quite simple. I have do the following: <code> template <typename Seq> struct or_seq; template <typename Seq, long N> struct or_seq_aux : mpl::or_< typename mpl::front<Seq>::type, or_seq<typename mpl::pop_front<Seq>::type> > {}; template <typename Seq> struct or_seq_aux<Seq, 1> : mpl::front<Seq>::type {}; template <typename Seq> struct or_seq : or_seq_aux<Seq, mpl::size<Seq>::value> {}; </code> Is there a boost or_seq like logical metafunction? Is there a better way to do it? I would be extremely interested in any suggestions. Best regards --------------------------- Vicente Juan Botet Escriba

5 34

Unable to compile boost.wave
by Sean Farrow 17 Jun '09

17 Jun '09

Hi: The following is my boost compile output when trying to compile the latest trunk. Boost.wave fails to compile, this seems to be an issue with boost.spirit. Visual c++ 2005/2008, all latest patches/service pacs applied, windows xp sp3. Any help appreciated. Sean. --start log. Building C++ Boost. After the build, the headers will be located at C:\Program Files\boost The libraries will be located at C:\Program Files\boost\stage\lib Use 'bjam install --prefix=<path>' if you wish to install headers and libraries to a different location and remove the source tree. warning: Building Boost.Regex with the optional Unicode/ICU support disabled. note: Please refer to the Boost.Regex documentation for more information note: this is a strictly optional feature. warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user_config.jam warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. ...patience... ...patience... ...patience... ...found 6725 targets... ...updating 12 targets... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_cpp_grammar.obj instantiate_cpp_grammar.cpp C:\Program Files\boost\boost/spirit/home/support/iterators/detail/split_std_deque_p olicy.hpp(102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/wave/grammars/cpp_grammar_gen.hpp(81) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] libs\wave\src\instantiate_cpp_grammar.cpp(45) : see reference to class template instantiation 'boost::wave::grammars::cpp_grammar_gen<LexIteratorT,TokenContainerT>' being compiled with [ LexIteratorT=lexer_type, TokenContainerT=token_sequence_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\inst antiate_cpp_grammar.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_cpp_grammar.obj... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_defined_grammar.obj instantiate_defined_grammar.cpp C:\Program Files\boost\boost/spirit/home/support/iterators/detail/split_std_deque_p olicy.hpp(102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/wave/grammars/cpp_defined_grammar_gen.hpp(42) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] libs\wave\src\instantiate_defined_grammar.cpp(41) : see reference to class template instantiation 'boost::wave::grammars::defined_grammar_gen<LexIteratorT>' being compiled with [ LexIteratorT=lexer_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\inst antiate_defined_grammar.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_defined_grammar.obj... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_predef_macros.obj instantiate_predef_macros.cpp C:\Program Files\boost\boost/spirit/home/support/iterators/detail/split_std_deque_p olicy.hpp(102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] C:\Program Files\boost\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] C:\Program Files\boost\boost/spirit/home/classic/tree/common.hpp(1531) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] C:\Program Files\boost\boost/wave/grammars/cpp_predef_macros_grammar.hpp(157) : see reference to class template instantiation 'boost::spirit::classic::tree_parse_info<IteratorT>' being compiled with [ IteratorT=boost::wave::cpplexer::lex_iterator<token_type> ] C:\Program Files\boost\boost/wave/grammars/cpp_predef_macros_grammar.hpp(157) : while compiling class template member function 'boost::spirit::classic::tree_parse_info<IteratorT> boost::wave::grammars::predefined_macros_grammar_gen<LexIteratorT>::pars e_predefined_macro(const boost::wave::cpplexer::lex_iterator<TokenT> &,const boost::wave::cpplexer::lex_iterator<TokenT> &)' with [ IteratorT=boost::wave::cpplexer::lex_iterator<token_type>, LexIteratorT=lexer_type, TokenT=token_type ] libs\wave\src\instantiate_predef_macros.cpp(41) : see reference to class template instantiation 'boost::wave::grammars::predefined_macros_grammar_gen<LexIteratorT>' being compiled with [ LexIteratorT=lexer_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\inst antiate_predef_macros.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi\instan tiate_predef_macros.obj... ...skipped <pbin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi>libb oost_wave-vc90-mt-gd-1_40.lib for lack of <pbin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi>inst antiate_cpp_grammar.obj... ...skipped <pstage\lib>libboost_wave-vc90-mt-gd-1_40.lib for lack of <pbin.v2\libs\wave\build\msvc-9.0\debug\link-static\threading-multi>libb oost_wave-vc90-mt-gd-1_40.lib... ...skipped <pstage\lib>libboost_wave-vc90-mt-gd.lib for lack of <pstage\lib>libboost_wave-vc90-mt-gd-1_40.lib... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_cpp_grammar.obj instantiate_cpp_grammar.cpp .\boost/spirit/home/support/iterators/detail/split_std_deque_policy.hpp( 102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous .\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] .\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/wave/grammars/cpp_grammar_gen.hpp(81) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] libs\wave\src\instantiate_cpp_grammar.cpp(45) : see reference to class template instantiation 'boost::wave::grammars::cpp_grammar_gen<LexIteratorT,TokenContainerT>' being compiled with [ LexIteratorT=lexer_type, TokenContainerT=token_sequence_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\in stantiate_cpp_grammar.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_cpp_grammar.obj... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_defined_grammar.obj instantiate_defined_grammar.cpp .\boost/spirit/home/support/iterators/detail/split_std_deque_policy.hpp( 102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous .\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] .\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/wave/grammars/cpp_defined_grammar_gen.hpp(42) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] libs\wave\src\instantiate_defined_grammar.cpp(41) : see reference to class template instantiation 'boost::wave::grammars::defined_grammar_gen<LexIteratorT>' being compiled with [ LexIteratorT=lexer_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\in stantiate_defined_grammar.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_defined_grammar.obj... compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_predef_macros.obj instantiate_predef_macros.cpp .\boost/spirit/home/support/iterators/detail/split_std_deque_policy.hpp( 102) : error C2440: '<function-style-cast>' : cannot convert from 'int' to 'boost::wave::cpplexer::lex_token<>' No constructor could take the source type, or constructor overload resolution was ambiguous .\boost/spirit/home/support/iterators/multi_pass.hpp(117) : see reference to function template instantiation 'void boost::spirit::iterator_policies::split_std_deque::unique<Value>::increm ent<boost::spirit::multi_pass<T,Policies>>(MultiPass &)' being compiled with [ Value=boost::wave::cpplexer::lex_token<>, T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type, MultiPass=boost::spirit::multi_pass<std::pair<boost::wave::cpplexer::imp l::lex_iterator_functor_shim<token_type>,boost::wave::cpplexer::lex_inpu t_interface<token_type> >,boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::impl::le x_iterator_functor_shim<token_type>>::policy_type> ] .\boost/spirit/home/support/iterators/multi_pass.hpp(115) : while compiling class template member function 'boost::spirit::multi_pass<T,Policies> &boost::spirit::multi_pass<T,Policies>::operator ++(void)' with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/wave/cpplexer/cpp_lex_iterator.hpp(170) : see reference to class template instantiation 'boost::spirit::multi_pass<T,Policies>' being compiled with [ T=std::pair<boost::wave::cpplexer::impl::lex_iterator_functor_shim<token _type>,boost::wave::cpplexer::lex_input_interface<token_type> >, Policies=boost::wave::cpplexer::make_multi_pass<boost::wave::cpplexer::i mpl::lex_iterator_functor_shim<token_type>>::policy_type ] .\boost/spirit/home/classic/tree/common.hpp(1531) : see reference to class template instantiation 'boost::wave::cpplexer::lex_iterator<TokenT>' being compiled with [ TokenT=token_type ] .\boost/wave/grammars/cpp_predef_macros_grammar.hpp(157) : see reference to class template instantiation 'boost::spirit::classic::tree_parse_info<IteratorT>' being compiled with [ IteratorT=boost::wave::cpplexer::lex_iterator<token_type> ] .\boost/wave/grammars/cpp_predef_macros_grammar.hpp(157) : while compiling class template member function 'boost::spirit::classic::tree_parse_info<IteratorT> boost::wave::grammars::predefined_macros_grammar_gen<LexIteratorT>::pars e_predefined_macro(const boost::wave::cpplexer::lex_iterator<TokenT> &,const boost::wave::cpplexer::lex_iterator<TokenT> &)' with [ IteratorT=boost::wave::cpplexer::lex_iterator<token_type>, LexIteratorT=lexer_type, TokenT=token_type ] libs\wave\src\instantiate_predef_macros.cpp(41) : see reference to class template instantiation 'boost::wave::grammars::predefined_macros_grammar_gen<LexIteratorT>' being compiled with [ LexIteratorT=lexer_type ] call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\in stantiate_predef_macros.obj.rsp" ...failed compile-c-c++ bin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi\inst antiate_predef_macros.obj... ...skipped <pbin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi>li bboost_wave-vc90-mt-1_40.lib for lack of <pbin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi>in stantiate_cpp_grammar.obj... ...skipped <pstage\lib>libboost_wave-vc90-mt-1_40.lib for lack of <pbin.v2\libs\wave\build\msvc-9.0\release\link-static\threading-multi>li bboost_wave-vc90-mt-1_40.lib... ...skipped <pstage\lib>libboost_wave-vc90-mt.lib for lack of <pstage\lib>libboost_wave-vc90-mt-1_40.lib... ...failed updating 6 targets... ...skipped 6 targets... --end log. __________ Information from ESET NOD32 Antivirus, version of virus signature database 4160 (20090616) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

2 1

Interest in a Bloom Filter?
by Dean Michael Berris 17 Jun '09

17 Jun '09

Hi Everyone, During the weekend, I got acquainted with and excited about Bloom Filters and the utility of such a data structure. I then proceeded to look at generic implementations of a bloom filter and I thought about implementing one myself instead as a simple exercise. Attached is what I came up with which I'm submitting as a library for review (and uploading to the vault). Also attached is a sample program which uses the bloom_filter. I've yet to write some documentation about it, which would be in the list of things to do in case there's enough interest for the library to be included in Boost. Thanks in advance and I hope this helps! -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

5 12

Boost on solaris compiled and linked with libCstd
by CREMARENCO Cosmin 16 Jun '09

16 Jun '09

Hi We have a solaris distribution of our software and we would like to use the boost libraries. In my understanding you recommend compiling and linking with stlport. However we depend on third party libraries that were built with libCstd, which is the old standard non-conformant library from sun. Sun docs clearly state that one should use either stlport or libCstd in the same program but not both. Also, we use sun studio 11. Now, we tried building boost with libCstd. A number of libraries built without problems: date, iostreams, prg, signals, system. In our application we use mostly header-only libraries and a small number of libraries that need to be linked with the program. We could get program-options (which we use extensively) to build by patching it (a tentative patch for 1.39 is attached). Of course one also needs to change tools/build/v2/tools/sun.jam in order to disable compiling and linking with stlport. My question is: if we send patches that allow boost to be compiled and linked with libCstd is there a chance that you will accept them in your main codeline? Best regards, Cosmin

2 1

[test] Untraceable Boost.Test framework internal error: unknown reason
by Peter Soetens 16 Jun '09

16 Jun '09

Hi, I'm using Boost 1.37.0 (Ubuntu Jaunty). When I run my testcases, they seem to complete well, but just before the end of the program exit, I get this error from Boost UTF: Boost.Test framework internal error: unknown reason FATAL: exception not rethrown Aborted I spent an hour trying to figure out 1) how to find out where the exception was thrown and 2) if the exception catching in boost could be disabled such that a simple gdb backtrace could point me to it. I have the suspicion that one of the signal handlers that boost UTF installs gets triggered, but I also did not find any way to disable the boost signal handlers. I'm really out of options... Any help/hints (would upgrading boost help?) really appreciated. Peter

2 3

[repost][threads] final decision on making parts of Boost.Threads header-only
by joaquin＠tid.es 16 Jun '09

16 Jun '09

I'm reposting this in the hope of catching the attention of the lib's author, who is at the end of the day the person reponsible of making the decision: Hi, A few weeks ago we had a discussion about the convenience of making part of Boost.Threads, namely mutexes and locks, header-only. Some (including Anthony Williams) supported the idea, others disliked it: http://lists.boost.org/Archives/boost/2009/04/150524.php What the final decision on this issue is? If positive (i.e. favoring the change), can it be expected to be done for Boost 1.40? As a remainder, I've created an associated trac ticket: https://svn.boost.org/trac/boost/ticket/2964 Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

Proposal: null pointer class
by Martin Törnwall 15 Jun '09

15 Jun '09

Hello Boost developers, I'd like to propose the inclusion of a null_ptr class in Boost. While I am fully aware that this topic has been brought up several times in the past, it appears as if though all discussions slowly died off without any final decision as to whether it is a worthy candidate for inclusion in Boost or not. The null pointer class proposals I have seen before were all designed to function in a manner similar to that of the "nullptr" keyword of C++0x. That is, the classes typically provided a template conversion operator, which allows it to evaluate to any pointer type with the value zero. My approach is to make the class, rather than the operator, a template: template<typename T> class null_ptr { public: operator T*() const { return reinterpret_cast<T *>(0); } }; As we can see, passing a null_ptr requires us to explicitly specify the type of pointer. While slightly verbose, I believe that it can be highly beneficial, for the following reasons: 1. In cases where multiple overloaded functions that take pointers exist, there is no way that we could accidentally call the wrong overload (since we have to explicity specify the type). 2. It makes code easier to read and understand. When reading the code, another programmer will instantly be able to see what type argument(s) a particular function accepts, thus making it much clearer than using NULL or nullptr. As with all other null pointer classes that have been suggested to date, the primary benefit of using my null_ptr over the NULL constant is that it solves the following problem: void f(int) { ... } void f(char *) { ... } int main() { func(NULL); func(null_ptr<char>()); } When passing NULL, f(int) will be called -- probably not what the programmer intended. The second call utilizes null_ptr<char> to guarantee that the overload of f() taking char* will be called instead of the one taking int. As noted above, my null_ptr class also handles multiple overloads taking pointer types gracefully. Please let me know what you think! P.S: I have tested the code on Microsoft Visual C++ 2008 as well as gcc 4.3.3 (Linux). Regards, Martin Törnwall

6 12