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

[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

A question about Units & Spirit
by John Phillips 15 Jun '09

15 Jun '09

In the middle of the directX thread, Daniel Duffy asked a question that seems more suited to its own thread. I'm starting that thread and giving others a chance to join into the discussion by giving you the content of the few messages that have passed by so far. John From Daniel --------------------------------------------------- Hello, This is my first mail, so I hope I have sent it to the right address :) I am using the Units library for Dimensional Analysis. So far it is very useful. Up till now I am using it in a hard-coded/compile time way as in a test.cpp. My inteterst is in using Units as part of a larger run-time system so I need some way of making my code more flexible. Lambda library is an option here but I would also like to create units and quanties from string input as well as being able to parse these strings to units and then store the units in a database. Can I use Spirit (and Serialization) for these features? Maybe the functionality already exist, and I have not found it. best regrads Daniel J. Duffy From Hartmut --------------------------------------------------- Sure Spirit is your friend for all parsing and output generation needs. What did you have in mind? Regards Hartmut From Daniel ---------------------------------------------------- Hartmut, I would like to generate well-formed units and create expressions of the followiong kinds: Examples of unit expressions: 1. 2m + 15m*32s/16s = 32m. 2. 3m*7s + 2m*10s/5m = 21m + 4s -> ERROR. Can't add meters to seconds. The second group looks more tricky. Examples of simplification: 1. (x-2)2 + 4x2 - 2^x + 1 = 5x2 - 8x + 10 2. x2 + 7x + 10 = (x + 2)(x + 5) 3. (a + b)(a - b) = a2 - b2 4. sin(x)2 + cos(x)2 = 1 5. 2sin(x)cos(x) = sin(2x) One tricky part is for example #5 where the code needs to 'know' trigonometry. best regards Daniel From John ---------------------------------------------------------- Daniel J. Duffy wrote: > Hartmut, > I would like to generate well-formed units and create expressions of the followiong kinds: > > Examples of unit expressions: 1. 2m + 15m*32s/16s = 32m. 2. 3m*7s + 2m*10s/5m = 21m + 4s -> ERROR. Can't add meters to seconds. So, you want this to happen at run time, or at compile time? At compile time, I think you are already set with the Units library. At run time, there are examples with the library that would help. If parsing the input is your concern, then Spirit is a good choice. (Spirit 2 is even better, by the way.) Using the two together, you could write a program where a user enters your example lines and gets correct responses. > > The second group looks more tricky. > > Examples of simplification: 1. (x-2)2 + 4x2 - 2^x + 1 = 5x2 - 8x + 10 2. x2 + 7x + 10 = (x + 2)(x + 5) 3. (a + b)(a - b) = a2 - b2 4. sin(x)2 + cos(x)2 = 1 5. 2sin(x)cos(x) = sin(2x) > One tricky part is for example #5 where the code needs to 'know' trigonometry. As far as I can tell here, you are looking for a program that does symbolic algebra. If that is true, then I don't think boost has a complete solution for you. Writing the parser for the input with Spirit wouldn't be that bad, but writing the processing engine that matches patterns and does simplifications is not covered by any current Boost libraries. I don't recall seeing anyone poll for interest on this, so I don't think there is even a partial library in the sandbox. Would you want this at run time, compile time, both? I haven't tried to write it, but I think a pure compile time implementation would be prohibitively slow. For a pure run time solution, you might consider linking to already existing solutions, such as Maple or Mathematica. > > best regards > > Daniel > John

2 2

[ptr_container] Can't store a pointer to const in multimap?
by Amit Kumar 15 Jun '09

15 Jun '09

Please consider the following code: #include "boost/ptr_container/ptr_map.hpp" int main() { typedef boost::ptr_multimap<char, const int> M; M m; char c = 'c'; int* j = new int(7); m.insert(c, j); return 0; } The gcc 4.3.3 compiler fails to compiler the above code. Am I doing something wrong by inserting a non-const? Can't I store a pointer to const in the multimap? try.cpp: In function ‘int main()’: try.cpp:8: error: expected primary-expression before ‘=’ token /usr/include/c++/4.3/bits/stl_pair.h: In constructor ‘std::pair<_T1, _T2>::pair(const std::pair<_U1, _U2>&) [with _U1 = char, _U2 = const int*, _T1 = const char, _T2 = void*]’: boost/boost_1_39_0/boost/ptr_container/ptr_map_adapter.hpp:765: instantiated from ‘typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::iterator boost::ptr_multimap_adapter<T, VoidPtrMultiMap, CloneAllocator, Ordered>::insert_impl(const typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::key_type&, typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::mapped_type) [with T = const int, VoidPtrMultiMap = std::multimap<char, void*, std::less<char>, std::allocator<std::pair<const char, void*> > >, CloneAllocator = boost::heap_clone_allocator, bool Ordered = true]’ boost/boost_1_39_0/boost/ptr_container/ptr_map_adapter.hpp:799: instantiated from ‘typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::iterator boost::ptr_multimap_adapter<T, VoidPtrMultiMap, CloneAllocator, Ordered>::insert(typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::key_type&, typename boost::ptr_container_detail::ptr_map_adapter_base<T, VoidPtrMap, CloneAllocator, Ordered>::mapped_type) [with T = const int, VoidPtrMultiMap = std::multimap<char, void*, std::less<char>, std::allocator<std::pair<const char, void*> > >, CloneAllocator = boost::heap_clone_allocator, bool Ordered = true]’ try.cpp:9: instantiated from here /usr/include/c++/4.3/bits/stl_pair.h:106: error: invalid conversion from ‘const void*’ to ‘void*’ I also tried but failed with const casting j before insertion.

3 2

[serialization][trunk] Latest patch for void_cast.cpp causes segfaults
by Hartmut Kaiser 15 Jun '09

15 Jun '09

Hi all, apparently the latest patch to boost/libs/serialization/src/void_cast.cpp (rev.53078, svn:date: 2009-05-18T06:25:56.023190Z, svn:author: ramey, svn:log: fix errors in extended_type_info management) causes an existing application to segfault during cleanup. The application was working properly before. The attached patch fixes the issue. Ok to commit? Regards Hartmut

1 0

Removing Bind placeholders from the global namespace
by Peter Dimov 15 Jun '09

15 Jun '09

This topic has again come up recently in boost-users. I have already assigned myself a ticket, https://svn.boost.org/trac/boost/ticket/2240 but have done nothing so far, in part because it would break other Boost libraries. (Patching placeholders.hpp is trivial in itself.) This is one case in which the trunk/release procedures don't work well as-is unless someone volunteers to produce a patch against all of Boost that at once moves the placeholders into namespace boost::placeholders _and_ fixes all errors that this would cause. It'd be easier to split the work: I put the breaking change in and then the libraries are fixed one by one. :-) Comments? -- Peter Dimov http://www.pdplayer.com

10 31

[candidate bloom_filter] nitpick
by JOAQUIN M. LOPEZ MUÑOZ 15 Jun '09

15 Jun '09

Hi Michael, I see that internals.hpp declares the following: namespace boost { namespace detail { template <class Input, class BitSet> class bloom_filter_internals {...}; } } boost::detail should not be used for internals of a specific library. The custom is to do it like this: namespace boost{ namespace bloom_filters{ namespace detail{ // you might want to rename to just "internals" // as the qualified name is sufficiently informative template <class Input, class BitSet> class bloom_filter_internals {...}; } } } Note the "s" in "bloom_filters", following the naming guidelines at: http://www.boost.org/development/requirements.html#Naming_consistency Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Boost and XML-RPC
by Dmitriy Lyfar 15 Jun '09

15 Jun '09

Hello boosters, What do you think about boost.xmlrpc implementation? Some days ago I need simple xmlrpc library with https support, but I cannot find anything for windows. What I've found it's http://libiqxmlrpc.sourceforge.net/ library. But it has too many dependencies, I really don't understand why I should compile half of gnome to have an ability call xmlrpc methods. So after some libs I realized that there is no good xmlrpc lib for windows at least (if you know, please let me know). So what are you thoughs about implementation such lib as part of boost (asio based for example)? Is it needed for community? Thank you, Dmitriy.

2 3

Blechmann's lock-free
by Michael Caisse 14 Jun '09

14 Jun '09

Tim - I just downloaded your lock-free data structure code and was getting ready to take a look at it. Two questions immediately come to my mind: 1. What is your intent for this library? Do you plan on having it reviewed? 2. Do you have pre-made docs available somewhere? I seem to consistently have troubles getting the doc chain going. Best Regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[date_time] Change to the time_duration default format.
by Ilya Bobir 14 Jun '09

14 Jun '09

Hi all, I would like to propose a change to the default format for the time_duration objects. Current format is "%H:%M:%S%f". It does not allow one to input a time_duration that is longer than 99 hours. My proposal is to change the format to be "%O:%M:%S%f". time_duration objects are not restricted to 99 hours so the current behavior seems to be incorrect. I have submitted a patch but was told that the change is a braking change and need to be discussed on a mailing list: https://svn.boost.org/trac/boost/ticket/1861#comment:3 Please reply if you think there could be issues with the change to the default time_duration format. Here is a simple test that shows what I'm talking about: #include <iostream> #include <sstream> #include <boost/date_time.hpp> using namespace std; using namespace boost::posix_time; int main(void) { time_input_facet* facet = new time_input_facet(); locale loc(locale(locale(), facet)); time_duration td1(hours(100)); time_duration td2; stringstream ss; ss.imbue(loc); /* Input using default time_duration format. */ facet->time_duration_format("%H:%M:%S%f"); ss << td1; ss >> td2; cout << td2 << endl; /* Input using proposed time_duration format. */ ss.str(""); ss.clear(); facet->time_duration_format("%O:%M:%S%f"); ss << td1; ss >> td2; cout << td2 << endl; } For me it outputs: 00:00:00 100:00:00 It means that you can not serialize and deserialize arbitrary time_duration objects if you are using the default format. While the output facet do write extra digits the input facet will accept only two digits for the hours field. Ilya Bobir

2 1

Re: [boost] first review submission of timer_queue.zip
by JohnQ 14 Jun '09

14 Jun '09

>> Thanks to any who take the time to review this and help me make it better. > >Why the call_back is associated to the timer_queue and not to the timeout? If I understand your question correctly, it's because this allows me to look at a "window" of time when the current timer expires. That way I can call the callback multiple times for timers that are all within the current "window" to avoid invoking context switches for each of those timers. > >Do we really need several timer queues? Shouldn't only one be enough? IMO the class timer_queue >muts be hiden to the user. The interface I would like to use is something like, > > auto h = after_call(miliseconds(10), f, x, y); >or > auto h = at_call(now()+miliseconds(10), f, x, y); > > if (some condition) { > h.interrupt(); > } Let me take a closer look at this and make another reply... I'm short on time right now... but I have a question about the first part... there should only be one timer queue... and actually the container behind the scenes is a multi-index map (not really a queue). > >The user should be also able to wait until the timeout has expired and the function called. So > > h.wait() > >will synchronize with the end of the function call f(x,y). If in addition f returns something the >following should also be correct > > auto res = h.get() > >So the handle returned by > auto h = after_call(miliseconds(10), f, x, y); > >must implement the future interface (an asynchronous completion token). I think I agree... but need more time to go through your suggestion. > >There are classic implementation using a well instead of a queue which make insertion independent >of the number of active timers (see for example "Redesigning >the BSD Callout and Timer Facilities" by Adam M. Costello, George Varghese > http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B5202FC949FF3EDB0E… ). > Yes, this is good advice... I'll take a look. >Best regards, >Vicente Excellent ! Thanks for giving this a detailed look Vicente. ----- From Dmitry---- >>>> What mechanism do you use to suspend till it's time to fire a callback? >>>> >> >> boost::condition_variable m_timed_cond.timed_wait(timer_lock, cur_timer) >> >> >This approach has a drawback. After the timeout expires timed_wait() has >to lock a mutex. And this can take arbitrary long. >Especially if there are other threads that are waiting for the same >mutex. Any thread that came before your thread will, most probably, >acquire the mutex before your thread. >This obviously spoils precision. Why dont you use a semaphore instead? >In order to improve precision, the library can also wait a bit less than >the client asked to give the thread some time to resume. Under high load >the scheduler can give your thread the processor long later than you asked. Thanks Dmity! As with my answers to Vicente above, let me take a closer look and reply. I've been completely swamped, the last 1-2 weeks and I'm just coming out of it. :) Thanks, John Q.

1 0

[PropertyTree] Rewrite - Please Review
by Sebastian Redl 13 Jun '09

13 Jun '09

Hi PropertyTree users, I have completed the main bulk of the property tree rewrite/cleanup. In the course of this, I have made the code standard-compliant (it previously used a std::list of an incomplete type, which is not, strictly speaking, valid), made it follow the claimed complexities (find() was O(n), although the docs said it's O(log n)), and revised the customization interface quite thoroughly. Inevitably, there were breaking changes in this process. I would ask everyone who has existing code using PropertyTree to look at these changes and tell me their best guess at how much effort it would be to update the code to conform with the new interface, and how I could make this easier. The development is still in a branch, so you need to check out the SVN branch http://svn.boost.org/svn/boost/branches/sredl_2009_05_proptree_update to try out the new version. The breaking changes are as follows: 1) Probably the most common change need: ptree::find() now returns the new type assoc_iterator (const_assoc_iterator for the const version) instead of iterator (const_iterator). This means that you need to change the type of the variable you capture the result with to assoc_iterator. It also means you need to compare the result of find() against ptree::not_found() instead of ptree::end(). You can get an iterator from an assoc_iterator by passing it to ptree::to_iterator(). The other projection direction is currently not supported, although it would be trivial to add. 2) The number and order of template arguments to basic_ptree has been changed. The old arguments were * Key comparison predicate * Key type * Path type * Data type * Translator type The new arguments are * Key type * Data type * Key comparison predicate (defaults to std::less<Key>) The old order prevented defaulting and wasn't very useful in general. The new order is consistent with std::map. The path and translator arguments have been removed to simplify the interface of basic_ptree. Equivalent functionality is available (see below). If you used your own instantiation of basic_ptree before, instead of simply using the (wi)ptree typedefs, you will have to adapt your code to the new order. If you used custom path and/or translator types, read on. 3) put and put_child previously had a final parameter 'bool do_not_replace'. I don't like boolean parameters, especially those whose name contains a negation. I removed the parameter, and replaced its functionality by a pair of new functions, add and add_child. If you previously called put or put_child passing true for do_not_replace, you must change these calls to add or add_child, respectively. If you ever passed false explicitly, you have to remove this parameter. 4) Using custom path types has changed. You can no longer create individual basic_ptree instantiations with custom path types. Instead, a key type has a fixed path type associated with it. I can bring this functionality back pretty easily if required, but I want to see use cases for this first. (Such things are why I make this call for reviews.) Less template parameters to ptree is good, in my opinion. To use a key type other than std::basic_string specializations, you have to specialize boost::property_tree::path_of for this key type. The path_of struct contains a single type called type, which is the path to use for this key type. The way paths are implemented has also changed thoroughly. Previously, you had to implement a const and a non-const variant of get_child, plus put_child (with do_not_replace making that effectively two functions too). These functions contained a lot of logic that really belonged into ptree, making implementing custom paths tedious and error-prone. The new interface requires you to implement four functions, but they're far simpler. The functions are described in ptree_fwd.hpp in C++0x concept syntax, but here's the gist: bool path::empty() const -> is the path empty? bool path::single() const -> does the path contain a single element? key_type path::reduce() -> chop off the first part of this path and return it (basically a pop_front that returns the value). std::string dump() const -> get a readable form of this path for exception messages; feel free to return "" here if you don't care. The new interface should be easy to implement, and the tree traversal is now where it belongs (in the internal implementation functions walk_path and force_path). 5) Using custom translators has changed. A ptree no longer has a fixed translator associated with it. Instead, you can supply a custom translator to every get_value/get/put_value/put operation or use the default, which depends on the tree's data type and the type you extract/insert. An example: ptree pt; pt.put("k1.k2", 100); // Uses the default translator for std::string+int. // Note: the explicit template parameter here will go away. float f = pt.get<float>("k1.k2", my_special_float_string_converter()); The tree's own data type is called the internal type, while the parameter/return type is called the external type. The default translator for a internal+external pair is set by specializing the boost::property_tree::translator_between struct. By default, PropertyTree supplies an id_translator for when the internal and external types are the same, and a stream_translator for converting between a basic_string and anything else. Together, they faithfully emulate the behavior of the old default translator. Writing a custom translator is easy. It's a class that provides two typedefs and two functions: typename internal_type -> the internal data type typename external_type -> the external data type optional<external_type> Tr::get_value(internal_type) -> convert from the internal to the external type, boost::none on failure optional<internal_type> Tr::put_value(external_type) -> convert from the external to the internal type, boost::none on failure That's it for the changes. The new version of property tree is not quite complete yet. I still need to polish the documentation a little and document the new extension mechanisms properly. I also need to clean up a little. Finally, the INI parser doesn't work at the moment. However, the main functionality (tested by property_tree_test) plus the XML, JSON and INFO parsers should all work now. Looking forward to your feedback. Sebastian

3 4

[lexical_cast] Volunteer testers needed
by Adam Badura 13 Jun '09

13 Jun '09

The attached file contains a modification to lexical_cast which I want to be included in Boost 1.40. However that requires testing since lexical_cast is widely used. I did my own tests but it is not enough. Thus I ask anyone willing to volunteer to use the attached code and notify about the result. The attached file should be used instead of Boost's lexical_cast. It adds boost::classic_lexical_cast which acts exactly as boost::lexical_cast with std::locale::classic as the global locale. Two things have to be tested. 1) [more important] Whether boost::lexical_cast works as previously after the changes. 2) [less important] Whether boost::classic_lexical_cast works as expected. The changes allow to use lexical_cast in locale-independent tasks (like serialization of data) through the boost::classic_lexical_cast in applications which set global locale to something else then the classic locale. Also having those changes easies possible addition of text-based conversion function talking arbitrary locale object. Thanks in advance to anyone who helps. Adam Badura

2 2

Doxygen and Boostbook
by Mathias Gaunard 13 Jun '09

13 Jun '09

While looking at the Boostbook documentation, I couldn't find documentation about how Doxygen documentation is transformed into Boostbook. I think documentation that says how one doxygen special block is transformed to a boostbook element would be useful, as well as how to generate boostbook elements from special blocks not supported by doxygen. For example, I don't know how to define concepts in Doxygen. Is such documentation available somewhere?

1 0

Performance of boost::mutex and boost::mutex::scoped_lock
by Zachary Turner 13 Jun '09

13 Jun '09

I have been doing some profiling using VTune recently to investigate the cause of some underperforming multi-threaded code, and it's possible that I'm not interpreting these results correctly, but if I am it's a little surprising. This isn't the best multi-threaded design in the world, but it's basically a naive implementation of a producer consumer that uses a deque as the production queue, a boost::mutex as the lock, and a boost::condition as a signal to wake up when there's stuff in the queue (queue comment about boost::circular_buffer, which this code really should be using instead). There is LOTS of context switching going on, basically I read a 4KB chunk of data from the filesystem, put it in the queue, the other threads takes the 4KB of data, does something with it, and this repeats for a really long time. Since it doesn't take a whole lot of time to read 4KB of data from the disk, you can tell that there are going to be zillions of context switches and contention going on. So on to the point. Obviously most of the time is spent in boost::detail::basic_timed_mutex::lock, but what's surprising is the breakdown of time inside the lock function: (Keep in mind this is not timed over a terribly long sample, hence the small numbers, but it is over thousands of actual locks, and ultimately this locking alone makes up a noticeable portion of the sample duration) boost::detail::basic_timed_mutex.lock Total Time: 1,032,486 microseconds (1.032 seconds) Total Wait Time: 505,884 microseconds (.505 seconds) It appears that only half the time is actually spent inside the lock, which is pretty crazy. The rest is spent doing computations, which doesn't seem right for a lock. I drilled down further and came up with this: boost::detail.get_system_time_sentinel Total Time: 266,657 microseconds Total Wait Time: 264 microseconds So that accounts for about half of the computational time. The rest is in a Windows system call somewhere that I was not able to drill into. I don't know about the details of date_time library, or much about the details of thread library either for that matter, but why is a time necessary here at all? This is eventually resolving down to a boost::detail::basic_timed_mutex, but there's nothing timed about the operations I've done. I simply did the following: boost::mutex m; boost::mutex::scoped_lock lock(m); //... This should ultimately result in an infinite timeout being specified to the system call, so all of this computation seems completely unnecessary. It seems like a scoped_lock should completely bypass anything having to do with date_time, and perhaps even normal timed locks should come up with a more efficient strategy. Thoughts?

4 4

[mpl] mpl::string, ok to merge to release?
by Eric Niebler 13 Jun '09

13 Jun '09

The mpl::string tests look OK to me on trunk, so I was planning on merging this to release for 1.40. Objections? Aleksey, I've had some problems generating the refmanual html from the rst source. It seems to go OK, but then some of the internal links are broken, and I can't figure what I'm doing wrong. Could you generate new html from the rst on trunk and commit it back to trunk? Please let me know the revision number after you do, and I'll merge it all to release in one go. Thanks. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

Re: [boost] boost::directx?
by Kasra 13 Jun '09

13 Jun '09

Hi guys, I have been following this thread but haven't really found the significance of boost::directx! If the purpose of the library is to create a comprehensive graphics library, choosing directx or infact any other API seems absurd. For example, ORGE is a graphics library that doesn't choose OpenGL over DirecX but provides a wrapping interface for a graphics library where this library's internal is OpenGL and DirectX depending on the platform. I just think if this library is going to established within boost, it requires a portable interface irrespective of the internals. With Best Regards --- Kasra Nassiri

16 41

Why the integration branchmust remain clean, etc.
by David Abrahams 12 Jun '09

12 Jun '09

I just realized I can articulate what's not working for me about the current trunk/release branch arrangement. * IIUC, there are always lots of failures on the trunk because there's no pressure to keep it clean. * Before I check in a change in one of my libraries, I want to make sure I haven't broken anything else in boost. So naturally, I run the whole regression suite (there oughta be a better way!) * But since the trunk is not clean, I spend a lot of time analyzing problems that have nothing to do with my library. That's a real disincentive to making changes in Boost. In fact, I am confident my low activity in the repo over the last year or so is primarily caused by the amount of labor associated with testing my changes. Now, maybe you'll suggest that I test my own library, then damn the torpedoes and check in the changes, and let other people complain to me when their libraries break. That would work... except that many people aren't paying attention to the health of their libraries on the trunk. I suppose another approach might be to test against the release branch, then svn switch to the trunk and check in my changes there. But that is still laborious. I'm not sure what to do about this, but it's really killin' me. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 10

Some good news for boost
by David Abrahams 12 Jun '09

12 Jun '09

Apparently we've been selected as an "alternate finalist" in the SourceForge Community Choice awards! They want us to answer some questions and provide some supporting material. If anyone else in the community would like to contribute to answering questions 1 and 2 below, that would be awesome. Marshall, you're the only person I know of that has any Boost-related video. What do you think about #4? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 5

Documentation Edits
by Zachary Turner 12 Jun '09

12 Jun '09

What is the standard protocol for editing documentation? It doesn't appear to be a wiki, unless you have to explicitly request write access in which I wasn't aware of that. The reason I ask is that there are many times where I've spent forever toiling over the documentation of some new library that I wasn't familiar with, because the documentation either provided no / insufficient samples, functions with very general names and one-liner documentation that says (for example) "runs the service". Which is pretty obvious when the function is called run, but no mention of the implications or what "running" even means. Other examples include lack of discussion over memory ownership (I spent 6 hours yesterday trying to trace down a memory corruption only to later find that in one of the many example programs for the library a single line comment that said "this causes X to take ownership of Y". If that had been in the documentation I would have spent 5 minutes tracing down the bug. So my point in all this is can the documentation be in wiki format, and as a fallback is there a way that someone other than a library owner/maintainer can edit it?

2 1

Re: [boost] Possible problem: Christian Schladetsch
by John Maddock 12 Jun '09

12 Jun '09

> Let's not turn an accidental mailing into a tar and feather. All things > said and done, he is at least attempting to contribute something to the > community. Indeed, can we please consider this thread closed now, Thanks, John Maddock. Boost Moderator.

1 0

1.40.0 showstoppers
by Vladimir Prus 12 Jun '09

12 Jun '09

During last release cycle, we talked that there should be a way to flag some issues as showstoppers for next release, so that next release is either delayed until the issue is fixed, or the issue is explicitly downgraded by the release team after consideration. However, I am not sure we've reached definitive agreement on how such issues should be marked. One proposal is to use the 'showstopper' status. Does that sound OK to our release managers? If so, shall this convention be documented somewhere, and should release procedures be adjusted to including checking this list prior to rolling betas and final release? I can do the necessary edits if everybod agrees, and tell me what to edit. Thanks, Volodya

1 0

Re: [boost] "boost cold shoulder" (was proposal for #pragmaonce support)
by Brian Wood 11 Jun '09

11 Jun '09

Sid Sacek writes: > I believe I belong to a third category that you didn't mention below: > 3. The middle-aged mellowed-out "try to always do the right thing", > "using namespace boost", crowd. I don't think doing the right thing implies automatically using a Boost library, but rather considering the options. I encourage people to "chew the meat and spit the bones" when it comes to Boost. Some of the libs are very helpful and are implemented well. Other libs have some problems -- http://webEbenezer.net/comparison.html<http://webebenezer.net/comparison.html> . I will say though that doing the right thing in my book usally means using Boost Intrusive and that Ebenezer Enterprises offers exclusive marshalling/serialization support for two Boost Intrusive containers. If there's interest in having marshalling support for other Intrusive containers, we are willing to consider adding more support in that area. Brian Wood Ebenezer Enterprises www.webEbenezer.net <http://www.webebenezer.net/> "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

1 0

[multi_array] Negative strides
by John Reid 11 Jun '09

11 Jun '09

I could not find any support in boost::multi_array for negative strides. Does anyone know what the rationale was for not implementing them? John.

3 6

Proposal for #pragma once support
by Zachary Turner 11 Jun '09

11 Jun '09

I would like to propose conditional support for #pragma once be added to all header files in boost. This would involve, at the beginning of every header file, a preprocessor check to determine whether or not the particular compiler is on a whitelist of known compilers to optimized #pragma once. If so, #pragma once is used. so, something like this: #if defined(_MSC_VER) /* || defined(OTHER_PRAGMA_ONCE_ENABLED_COMPILER) ... */ #pragma once #endif the rest of the header file, including the original #include guard, could be as normal. to demonstrate the motivation for this, consider the sample on this page: http://www.gamearchitect.net/Articles/ExperimentsWithIncludes.html. At the bottom there is a zip file with a visual studio solution that contains 3 different projects. Each project contains 200 header file, each of which includes all of the other 199 header files. There is a single cpp file with a main function which includes all 200 header files. All 3 projects use internal #include guards. In addition: Project 'RedundantGuard' - Uses external include guards (wrapping the invocation of #include itself inside the appropriate guard) as discussed in the book Large Scale C++ Software Design Project 'PragmaOnce' - Uses #pragma once Project 'Nothing' - Uses nothing additional other than the internal include guards. Here are the build timings on my machine (Visual Studio 2008 Service Pack 2) RedundantGuard - 1 second compile + link time PragmaOnce - 1 second compile + link time Nothing - 15 seconds compile + link time In addition I have tested this in the code base of a commercial product I am working on (~40,000 lines of code). It consists of about 6 different projects, some of which have dependencies between each other and some which don't, so that parallel compilation can happen in some instances RedundantGuard - Not Tested PragmaOnce - 1 minute, 25 seconds compile + link time Nothing - 2 minutes, 1 second compile + link time So, I believe that boost compile times can benefit significantly from this. Thoughts?

20 38

Re: [boost] Proposal for #pragma once support
by Zachary Turner 11 Jun '09

11 Jun '09

On Tue, Jun 9, 2009 at 11:50 AM, <dherring(a)ll.mit.edu> wrote: > On Tue, 9 Jun 2009, Zachary Turner wrote: > > Here are the build timings on my machine (Visual Studio 2008 Service Pack >> 2) >> >> RedundantGuard - 1 second compile + link time >> PragmaOnce - 1 second compile + link time >> Nothing - 15 seconds compile + link time >> > ... > >> So, I believe that boost compile times can benefit significantly from >> this. >> >> Thoughts? >> > > Could you run benchmarks on gcc? Will my compile times suffer for your > improvement? > > - Daniel > It seems someone else in the thread has already run benchmarks on GCC, but regardless of how the benchmarks did or did not turn out, I can say with 100% certainty that nobody will suffer. That's the exact reason I mentioned that compilers should be whitelisted based on which ones benefit from #pragma once, and only use #pragma once for said compilers. #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif That's all it takes. Everybody benefits. Of course I don't have licenses for every C++ compiler around, but I'm sure there are other compilres in which it benefits also. So I would need some assistance from other people who do have other compilers to help find out which compilers it does offer an improvement on. And of course, the default would be to NOT use pragma once, erring on the side of caution. If you see any downsides to this approach let me know, but it seems like a win/win for everyone. To make it even more explicit, there could even be a global macro, which defaults to undefined, called BOOST_USE_PRAGMA_ONCE. The programmer would be forced to explicitly declare this macro before including any boost headers, and if it is enabled, boost would use pragma once.

9 16

possible problem with boost::iostreams::file_descriptor
by Zachary Turner 11 Jun '09

11 Jun '09

nested file_descriptor implementation class is defined as follows: struct impl { impl() : #ifdef BOOST_IOSTREAMS_WINDOWS handle_(reinterpret_cast<handle_type>(-1)), #else handle_(-1), #endif flags_(0) { } impl(handle_type fd, bool close_on_exit) : handle_(fd), flags_(0) { if (close_on_exit) flags_ |= impl::close_on_exit; } ~impl() { if (flags_ & close_on_exit) close_impl(*this); } enum flags { close_on_exit = 1, append = 4 }; handle_type handle_; int flags_; }; In the second constructor in particular we have this: impl(handle_type fd, bool close_on_exit) : handle_(fd), flags_(0) { if (close_on_exit) flags_ |= impl::close_on_exit; } I think this should be changed. Just because close_on_exit is specified to false does not mean a file is not open. It just means don't close it if it is. I think flags enumeration should be changed to: enum flags { close_on_exit = 1, good = 2, append = 4 }; and constructors / code should be changed accordingly. Otherwise following code (Windows) asserts, even though I don't think it should: bool is_open(HANDLE h) { return h && h!=INVALID_HANDLE_VALUE;} HANDLE h = ::CreateFile("C:\\autoexec.bat", GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL); boost::iostreams::file_descriptor fd(h, false); BOOST_ASSERT(fd.is_open() == is_open(h)); Thoughts?

3 5

Re: [boost] Proposal: Monotonic Containers: Performance test
by Christian Schladetsch 11 Jun '09

11 Jun '09

void test_speed() { typedef monotonic::map<int, monotonic::list<int> > map_with_list; monotonic::inline_storage<1000000> storage; map_with_list m(storage); size_t count = 10000; boost::timer timer; for (size_t i = 0; i < count; ++i) { int random = rand(); map_with_list::iterator iter = m.find(random); if (iter == m.end()) m.insert(make_pair(random, monotonic::list<int>(storage))); else iter->second.push_back(i); } double elapsed = timer.elapsed(); cout << "monotonic: " << elapsed << endl; // do the same thing, with std::containers { typedef std::map<int, std::list<int> > map_with_list; map_with_list m; for (size_t i = 0; i < count; ++i) { int random = rand(); map_with_list::iterator iter = m.find(random); if (iter == m.end()) m[random] = std::list<int>(); else iter->second.push_back(i); } double elapsed = timer.elapsed(); cout << "std: " << elapsed << endl; } } monotonic: 0.005 std: 0.09

4 5

bug-sprint #2114, 2 comments
by Alexander Arhipenko 11 Jun '09

11 Jun '09

I have 2 major comment on the updated patch. Consider following snippet from gcc.hpp: #if __GNUC__ >= 4 && !defined(__MINGW32__) && !defined(__CYGWIN__) # define BOOST_SYMBOL_EXPORT __attribute__((visibility("default"))) # define BOOST_SYMBOL_HIDE __attribute__((visibility("hidden"))) # define BOOST_SYMBOL_IMPORT BOOST_SYMBOL_EXPORT ...And assume following scenario: Someone is writing shared library (let's name it foo) with 'visilibility=hidden' option. Library foo is using e.g. boost_filesystem. In this case, all the symbols marked with BOOST_FILESYSTEM_DECL will be exported from foo library. This could easily break foo library's ABI (in case of migration to the newest boost version etc.), so BOOST_SYMBOL_IMPORT should be defined for gcc as empty macro: # define BOOST_SYMBOL_IMPORT. The second comment: BOOST_EXCEPTION_EXPORT/IMPORT are intended for re-exporting exceptions from shared library. So, they should be defined for gcc as: # define BOOST_EXCEPTION_EXPORT BOOST_SYMBOL_EXPORT # define BOOST_EXCEPTION_IMPORT BOOST_SYMBOL_EXPORT and not as: # define BOOST_EXCEPTION_EXPORT BOOST_SYMBOL_EXPORT # define BOOST_EXCEPTION_IMPORT BOOST_SYMBOL_IMPORT Note: for the current patch version this part works as expected, since BOOST_SYMBOL_EXPORT == BOOST_SYMBOL_IMPORT for gcc. See also this thread (search for exception): http://lists.boost.org/Archives/boost/2008/12/146068.php Regards

4 8

[candidate bloom_filter] Default Sequence
by JOAQUIN M. LOPEZ MUÑOZ 11 Jun '09

11 Jun '09

Currently, the default Sequence template arg is class Sequence = fusion::vector< detail::default_hash<0>, detail::default_hash<1>, detail::default_hash<2> > which implies the default K is 3. I propose to generalize this a bit so that we have something like template<typename K> default_hash_sequence...; such that default_hash_sequence<K> is the fusion sequence default_hash<0>,...,default_hash<K-1> (I don't know Fusion but I'm sure this can be done) and then put class Sequence = default_hash_sequence<3> So, a user can easily set bloom_filter<foo,default_hash_sequence<K> > with a K other than 3. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Proposal: Monotonic Containers
by joaquin＠tid.es 10 Jun '09

10 Jun '09

Stewart, Robert escribió: > joaquin(a)tid.es wrote: > On Tuesday, June 09, 2009 9:34 AM > >> Stewart, Robert escribió: >> >>> There's a problem with using an allocator for the node based >>> containers: they use the allocator to allocate the elements >>> but not the nodes. That implies free store (de)allocations >>> for the nodes which is contrary to the intended purpose of >>> this proposal. >>> >> Umm, I beg to differ. If we have a node-based container >> >> xxx<T,...,custom_allocator<T> > >> >> and node<T> is the internal node type, the container is required >> to do the allocation using an allocator of type >> >> custom_allocator<T>::rebind<node<T> >::other. >> >> The container is not allowed to do any kind of allocation using >> other means than the custom_allocator<X> family of allocators. >> > > If custom_allocator<node<T> > is not specialized to do the same as > custom_allocator<T>, or to use the same memory pool, then it > doesn't fit the proposal. Point conceded, but how would you do otherwise? Specifying a custom allocator is your only way to affect the container's allocation behavior. Seems like you're implying that the container wrapping approach is in some way more powerful than directly specifying the custom allocator, which is not. Your only chance to solve the problem you mention is to make custom_allocator<node_type<T> > use the same memory pool. There's a way to do this. If you construct the container with custom_allocator<T> a; xxx<T,...,custom_allocator<T> > x(a); then xxx will use an object of type custom_allocator<node<T> > for its allocation needs, which perforce will be an object differnt to the allocator a you've passed; but the container is required to construct this internal allocator as a copy of a: // inside xxx implementation custom_allocator<node<T> > internal_a(a); So you can use this knowledge to pass info around, for instance on the memory pool to be used. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

10 26

first review submission of timer_queue.zip
by JohnQ 10 Jun '09

10 Jun '09

Hi, Thanks for pointing me to the submission requirements page... I just uploaded timer_queue.zip to boost vault for first review. Haven't got everything shipshape yet but I'm hoping I've satisfied enough of the requirements so I can start getting some feedback on functionality. If not, let me know so I can rework and resubmit. In essence, timer_queue is a library for creating timers that fire at some arbitrary time in the future and hand you back a void* that you provided when you created the timer. Timers can be deleted before they fire by providing an id (can be non-unique) when you create a timer that can be used to delete particular sets of timers later on. Thanks to any who take the time to review this and help me make it better. John Q.

2 1

[mpl]iter_fold_if Forward Backward rationale?
by Larry Evans 10 Jun '09

10 Jun '09

Why is there both a ForwardOp and BackwardOp template argument to iter_fold_if? https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp#L… I would have thought that only 1 was needed. Since iter_fold_if is not documented here: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/refmanual_toc.h… I assume it's not meant to be used by the user, but is only an implementation detail; however, it, or a variation, might be useful to implement the and_seq mentioned here: http://article.gmane.org/gmane.comp.lib.boost.devel/186204 As shown in that post, the template, while_if_then was used, and it does not require anything like both a ForwardOp and BackwardOp, it just requires the If and Then unary metafunctions. One problem I encountered with while_if_then was moving to the end of the sequence, at which time the Then metafunction couldn't be called; hence, I had to make it lazy to avoid dereferencing the end iterator. Is that somehow related to the need for BackwardOp in iter_fold_if. IOW, because iter_fold_if might reach the end iterator, it has to backup? I'm really asking because in the variadic template version of mpl, I wondering if iter_fold_if could be replaced with something like while_if_then (which may be renamed fold_if to be more consistent with other names with similar function). Any insight about the rationale for the iter_fold_if would probably save me considerable time in deciding whether it can be replaced with the proposed fold_if. -regards, Larry

3 28

[filesytem][1.39.0] basic_path::clear mia?
by Jeff Flinn 10 Jun '09

10 Jun '09

http://www.boost.org/doc/libs/1_39_0/libs/filesystem/doc/reference.html#bas… lists void clear(); as an available modifier on basic_path. Neither I nor MSVC8 seem to be able to find it. Am I doing something wrong? Thanks, Jeff

1 0