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

[optional] generates unnessesary code for trivial types
by Hite, Christopher 12 Feb '12

12 Feb '12

When decompiling my code I noticed a bunch of unnessesary code caused by boost::optional. 1) deconstruction typedef boost::optional<int> optional_int; void deconstruct_boost_optional(optional_int& o){ o.~optional_int(); } One would expect this to do nothing. Instead gcc 4.6.0 with O3 generates: if(m_initialized){ // do nothing m_initialized = false; } 00000000 <deconstruct_boost_optional(boost::optional<int>&)>: 0: 8b 44 24 04 mov 0x4(%esp),%eax 4: 80 38 00 cmpb $0x0,(%eax) 7: 74 03 je c <deconstruct_boost_optional(boost::optional<int>&)+0xc> 9: c6 00 00 movb $0x0,(%eax) c: f3 c3 repz ret This one could be easily fixed by removing the bit that sets m_initialized to false, since we're deconstructing anyway. 2) assignment also generates these problems: void assign_boost_optional(optional_int& o){ o=13; } Here there's a semantic issue: we have to decide to use the copy constructor or operator=. This is also wasteful for POD types or any type which has_trivial_copy<>. 3) Even more expensive is if we want to copy an optional<int> void assign_boost_optional(optional_int& a,optional_int& b){ a=b; } 00000000 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)>: 0: 8b 44 24 04 mov 0x4(%esp),%eax 4: 8b 54 24 08 mov 0x8(%esp),%edx 8: 80 38 00 cmpb $0x0,(%eax) b: 74 0b je 18 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x18> d: 80 3a 00 cmpb $0x0,(%edx) 10: 75 16 jne 28 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x28> 12: c6 00 00 movb $0x0,(%eax) 15: c3 ret 16: 66 90 xchg %ax,%ax 18: 80 3a 00 cmpb $0x0,(%edx) 1b: 74 09 je 26 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x26> 1d: 8b 52 04 mov 0x4(%edx),%edx 20: c6 00 01 movb $0x1,(%eax) 23: 89 50 04 mov %edx,0x4(%eax) 26: f3 c3 repz ret 28: 8b 52 04 mov 0x4(%edx),%edx 2b: 89 50 04 mov %edx,0x4(%eax) 2e: c3 ret Three possible branches! Theoretically single 64 bit copy do the job. I'm tempted to say: it would be best if for any T has_trivial_copy< optional<T> > iff has_trivial_copy<T>. It might make a sense to make an exception for huge T, where the copying an unused T is more expensive than the branching. 4) has_trivial_destructor<T> should impl has_trivial_destructor< optional<T> > , but this is hard to implement without specialization of optional. Checking has_trivial_destructor might take care of the complexity of optional<T&> since has_trivial_destructor< T& >. I'd be willing to fix #1. The other issues need some discussion. Chris

14 39

How to make tests building faster?
by Mateusz Łoskot 10 Feb '12

10 Feb '12

Hi, I'm trying to figure out if there is anything I could do to improve compile/link-time for tests of Boost.Geometry library. Currently, the tests follow fairly canonical approach in Boost: 1) Each .cpp file defines a single test program and all local test routines are executed from test_main() // test_feature_x.cpp void test1() {} // make use of BOOST_CHECK_* macros void test2() {} int test_main(int, char* []) { test1(); test2(); return 0; } 2) Jamfile per testing project builds and runs each program separately # features/Jamfile.v2 test-suite test-features : [ run test_feature_x.cpp ] [ run test_feature_y.cpp ] ; 3) Root mylib/test/Jamfile.v2 defines testing projects to build and run import testing ; project boost-mylib-test : ; build-project features ; build-project algorithms ; build-project abc ; In total, there are nearly 170 test programs in Boost.Geometry. Obviously, running the whole set of tests (b2 command issued in libs\geometry\test) is time consuming process. I'm wondering if there is any way to reorganise the tests to cut down the build (linking) time. My first idea is to decrease number of run entries (e.g. [ run test_feature_y.cpp ] ) in Jamfiles, by building related tests as single test suite program. Conceptually: [ run test_feature_x.cpp test_feature_y.cpp ] Currently, there is no use of Boost.Test features for tests organisation like BOOST_AUTO_TEST_CASE BOOST_TEST_SUITE etc. I wonder if use of any of the above would help in restructuring tests and decreasing number of programs to build. Another aspect of Boost.Geometry tests I'd like to improve is to improve tests report output. Currently, it is reported as *Passed* or *Failed*. I presume that using Boost.Test to group tests in suits with test cases would improve test report providing details about location of failure (which suite, which case, or even better). I'm looking for any piece of advice on the issues discussed above: - How to cut down build time of tests? - How to improve test output report (and keep it suitable for Boost regression testing framework)? - Is it advised to switch to use Boost.Test features to manage suites and test cases? (I tried to figure it out browsing tests of other libs, but it doesn't indicate any preferred practice). I'd be thankful for any insights. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

10 34

[hash] regular behaviour of hash function for double values
by Kai Schroeder 07 Feb '12

07 Feb '12

Hi, the following code: double fStart = 31337; double fEnd = 65536; double fStep = fStart - fEnd; fStep /= 512; for (int i = 0; i < 512; i++) { std::cout << std::hex << boost::hash<double>()(fStart + i * fStep) << std::endl; } leads to the output of surprisingly regular hash values (see end of mail). This seems to occur mainly if a power of two number of points is sampled equidistantly within an interval. Especially since some hash table implementations (e.g. intel's threading building blocks) only use the last few bits to determine the bucket, this can lead to very bad caching behaviour for the rather common case of regularly sampled points (equidistant samplings of power of 2 are e.g. common in computer graphics and numerical algorithms). Are you aware of this? Would you consider it a bug? Best regards, Kai Schroeder Output of code using Boost 1.48 (similar behaviour can be observed for other start and end values and other power of 2 step counts): ff9f20000000000f e5042f900000000f 52f13f200000000f 297ac8b00000000f 48721e400000000f 2f9b8dd00000000f 3df0b1600000000f d19cf2f00000000f 9201c800000000f 9409aa100000000f 7cb3fba00000000f d7a42b300000000f b15982c00000000f 5f7900500000000f e0ba85e00000000f 255ee5700000000f cec119000000000f 955bd6900000000f 6a58f4200000000f 843a37b00000000f 590797400000000f 7e8db4d00000000f 1721b6600000000f 37acf9f00000000f df5f65800000000f 88b1a5100000000f 494a0a00000000f bb1082300000000f 1ea62bc00000000f ...

11 43

unordered_map 32bit VS 64bit
by Avikam Bara-nes 07 Feb '12

07 Feb '12

Hi, I'm porting a project from Linux 32bit to Linux 64bit. While doing so I notice that I have a dramatic performance degradation with unordered_map. My platform is Ubuntu 10.4.3 64bit running on Intel Xeon X3220 but, I tested similar program on WindowsXP SP2 64bit which running on Intel i5 and I get the same degradation. My boost version is 1_46_1. I use the following program in order to test unordered_map - Hop I didn't make any copy mistakes :-). #include <stdio.h> #include <sys/time.h> #include <boost/unordered_map.hpp> int main(int argc, char *argv[]) { struct timeval tv_before, tv_after; boost::unordered_map<boost::int_32_t, boost::int32_t> boost_map; boost_map[1] = 2; boost_map[3] = 4; gettimeofday(&tv_before, NULL); for(int i = ; i < 100000; i++) boost_map.find(1); gettimeofday(&tv_after, NULL); printf("Boost time is %f \n", (double)(((tv_after.tv_sec - tv_before.tv_sec) * 1000000 + (double)(tv_after.tv_usec - tv_before.tv_usec)) / 100000)); return 0; } I use the following compile commands: 64bit - g++ -O3 perf_test -o perf_test_64bit 32bit - g++ -m32 -O3 perf_test -o perf_test_32bit When I run the 32bit program I get 0.5 sec When I run the 64bit program I get 1.54 sec Any ideas ???

6 16

[functional] adding overload
by Lorenzo Caminiti 06 Feb '12

06 Feb '12

Hello all, During Boost.Local review, it was proposed to move the overload template out of Local and in Boost.Functional. What would the best name for it? 1) boost::overload_function (my preference) 2) boost::overloaded_function 3) boost::function_overload 4) boost::functional::overload (Boost.Functional seems to use boost:: directly and not boost::functional-- to mimic C++11 <functional>). For example: void print_text(char const* text) { std::cout << text << std::endl; } void print_add(int x, int y = 10) { std::cout << (x + y) << std::endl; } boost::function<void (int, int)> f = print_add; boost::overload_function< void (char const*) , void (int, int) , void (int) > print(print_text, f, print_add); print("abc"); // abc print(1, 2); // 3 print(1); // 11 Docs: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… Thanks. --Lorenzo

8 18

[filesystem] windows/posix inconsistencies.
by Thorsten Ottosen 06 Feb '12

06 Feb '12

Hi Beman, I noticed the following in v3 whie hunting down a bug in my unit test: # ifdef BOOST_WINDOWS_API const std::string string() const { return string(codecvt()); } const std::string string(const codecvt_type& cvt) const; // string_type is std::wstring, so there is no conversion const std::wstring& wstring() const { return m_pathname; } const std::wstring& wstring(const codecvt_type&) const { return m_pathname; } # else // BOOST_POSIX_API // string_type is std::string, so there is no conversion const std::string& string() const { return m_pathname; } const std::string& string(const codecvt_type&) const; const std::wstring wstring() const { return wstring(codecvt()); } const std::wstring wstring(const codecvt_type& cvt) const # endif I can understand, that it is more efficient to return a reference when a referenec can be formed. However, consider const std::string& ext = iter->path().extension().string(); This is fine on windows, as a temporary is returned, and its lifetime is extended; on linux, extension() returns a temp path object, from where we get a reference. I'm not a 100% sure, but I think the C++ standard does not guarantee that this path object be kept alive. The net efffect is a crash on linux. I'm not sure its a great idea to have different reference-ness on the return types here. It could lead to other subtle differences. kind regards -Thorsten

9 14

[mpl] Nested Scopes w/Placeholders
by Kitten, Nicholas 06 Feb '12

06 Feb '12

I've recently been doing a lot mpl::folding (in boost 1.47), and I was disappointed when I realized that a nested fold wouldn't work with a lambda expression passed to the inner call, as in this example which extracts elements of sequences: using namespace mpl; using namespace mpl::placeholders; typedef vector< vector<char>, vector<int> > vec_of_vecs; typedef vector< char, int > expected_result; typedef fold< vec_of_vecs, vector<>, fold< _2, _1, *push_back< _1, _2 >* // wrong - refers to outer arguments > >::type result; BOOST_MPL_ASSERT(( equal<result, expected_result> )); After looking around for a solution I came across an old thread<http://lists.boost.org/boost-users/2004/12/9269.php> on the same subject, where it was suggested using mpl::protect might work. Indeed, the following modification does what I want, without any changes to the library: typedef fold< vec_of_vecs, vector<>, fold< _2, _1, *protect< lambda< push_back< _1, _2 > >::type >* // correct > >::type result; Of course, this is a little on the verbose side. In the old thread, Daniel Wallin suggested suggested changing the definition of lambda to yield syntax more in line with the runtime version of boost::bind, but that would apparently break other code. What about instead adding a specialization to protect for placeholder expressions? Indeed, the source in protect.hpp seems to indicate such a thing might've been in the works at one point, but I didn't see any more references to it: template< typename BOOST_MPL_AUX_NA_PARAM(T) * , int not_le_ = 0 // not lambda expression?* > struct protect : T { ... typedef protect type; }; What about changing it to something like this? template< typename BOOST_MPL_AUX_NA_PARAM(T) * , typename not_le_ = typename is_lambda_expression< T >::type* > struct protect : T { ... typedef protect type; }; *template< typename T >* *struct protect< T, mpl::true_ > : lambda<T>* *{* *...* *typedef protect type;* *};* Doing so would remove the inner lambda<...>::type expression, yielding the expected syntax. Could that be done without messing up everything else? Thanks, *Nick Kitten* Software Engineer Center for Video Understanding Excellence ObjectVideo, Inc.

3 6

1.49.0 Beta 1 Release Candidate
by Steve M. Robbins 04 Feb '12

04 Feb '12

Hi, I'm starting a build (using the Debian package configuration) and noticed several known bugs still present: These two bugs are patched on the trunk but not release. Can these be moved over, please? https://svn.boost.org/trac/boost/ticket/4657 https://svn.boost.org/trac/boost/ticket/6338 This issue has a simple patch that works around the problem for gcc versions prior to 4.6.3: https://svn.boost.org/trac/boost/ticket/5538 This issue has a patch that works (is used in Debian), though a jam expert could likely find a better fix: https://svn.boost.org/trac/boost/ticket/6286 Regards, -Steve (Boost maintainer for Debian)

5 9

[random] Determining interest in Pseudo-Random Functions and Counter Based Random Number Generators
by John Salmon 03 Feb '12

03 Feb '12

I am co-author of "Parallel Random Numbers, as Easy as 1, 2, 3". which recently won the best paper award at the IEEE/ACM SC'11 conference. I'm also co-author of the related Random123 library: http://deshawresearch.com/resources_random123.html My colleagues and I would like to contribute a similar library to Boost as well. This isn't just a "port" of the Random123 library. Boost's focus on C++ allows for both simplification and clarification of the ideas in the paper and the original library. I've done a preliminary draft of some code that fits nicely into the existing Boost Random library. It's incomplete, but I think there's enough for folks to look at and gauge further interest. A zip file with a boost-like layout is here: http://thesalmons.org/john/random123/prf_boost/prf_boost.zip The README from the zip file is appended. I look forward to your comments and suggestions. John Salmon -------------- README ------------------- This extension of the Boost Random library adds "Pseudo-Random Functions" (PRFs) as an alternative to conventional "Uniform Random Number Generators" and "Random Number Engines". It is an incomplete draft, intended to start a conversation. It is not ready-to-use library. The case for using PRFs in Monte Carlo and statistical simulation is given in the paper, "Parallel Random Numbers -- As Easy as 1, 2, 3", by Salmon, Moraes, Dror & Shaw, in the Proceedings of SC'11: http://dl.acm.org/citation.cfm?doid=2063405 also available at http://www.thesalmons.org/john/random123/papers/random123sc11.pdf PRFs have been known for many years, but either their advantages were unrecognized or they were thought to have poor performance with respect to conventional URNGs. The paper shows that PRFs exist with excellent statistical properties, and highly desirable space and time characteristics. Also, note that the terminology in the paper, is slightly different from that used here. In the paper they're called "Counter Based Random Number Generators". PRFs are well-known in cryptography, but the PRFs here (except for AES) are *not* cryptographically strong. Nevertheless, they have satisfied extensive tests of statistical quality and should satisfy the needs of Monte Carlo simulation and other fields that routinely use random numbers. PRFs are pure functions (functors in C++) with the property that they return "random" values, even when presented with highly regular inputs (see the paper for a discussion of how randomness is empirically established). The user of a PRF assembles the input, calls the function and obtains a "random" result which can then be used in the same way as a value obtained from a conventional URNG or Engine. In contrast, a conventional Random Number Engine has a much more limited API: the caller is restricted to seeding the engine, once and for all, and then repeatedly asking for the "next" random value. PRFs eliminate the sequential dependence inherent in conventional RNGs. With a PRF, one can compute the "n-th" value in O(1) time, without stepping through earlier values. In fact, with a PRF, the notion of an "n-th" value loses its significance. One simply obtains a random value. Eliminating sequential dependence can be especially useful for parallel, multi-threaded applications. For example, one can assemble a PRF's input from application-level data, e.g., object id, voxel number, user-supplied seed value, timestep, iteration number, etc. This kind of application data is unchanged when the application is parallelized, and is generally invariant as more or fewer threads become available. The resulting random value is thus invariant to the parallelization as well. This can be enormously helpful when correctness dictates that separate "parallel" threads should use the same "random" value, or when trying to reproduce results on different platforms with different levels of parallelism. Four PRFs are implemented: threfry, philox, ars and aes, each implemented in its own header file, e.g., boost/random/ars.hpp. The file boost/random/counter_based_urng.hpp implements the counter_based_urng adapter class, which creates a Uniform Random Number Generator from a PRF, allowing programmers to use the PRF APIs together with Boost or C++1x Random Number Distributions. The file boost/random/counter_based_engine.hpp implements the counter_based_engine adapter class, which creates a Uniform Random Number Engine from a PRF, allowing PRFs to be used with software that relies on the Uniform Random Engine concept. For better or worse, wrapping a PRF in a counter_based_engine adapter completely obscures the PRF's API and reintroduces sequential dependence. The zip file also contains a copy of the candidate Boost Endian library copied from boost sandbox. Endian-swapping is required by the AES engine on bigendian machines, and the library meets our needs. Concepts -------- All PRFs have a domain_type and a range_type and with d a "permissible" object of the domain type, the expression: prf(d) is of the range_type. In many cases, every possible value of domain_type will be "permissible", but we leave open the possibility that the prf may place restrictions on the values of domain_type that produce "random" results. The values returned by the prf should be "random", a concept that is difficult to make both precise and achievable. Roughly, for most sequences, including highly "regular" sequences, of distinct, permissible domain_type values, d1, d2, d3, ..., the sequence: prf(d1), prf(d2), prf(d3), ... is statistically indistinguishable from a sequence of independent, uniformly distributed random variables sampling the range_type. In most cases, the output of the prf will uniformly sample all possible values of the range_type, but we leave open the possibility that it may only sample a subset and that the output is only uniform over the subset. Keyable PRFs have a key_type, a corresponding constructor, and setkey() and getkey() member functions. Keyable PRFs constructed with different keys must also be statistically independent. I.e., even for highly regular sequences of distinct (key, domain) pairs: (k1, d1), (k2,d2), ... the sequence: Prf(k1)(d1), Prf(k2)(d2), ... is statistically indistinguishable from a sequence of independent random uniformly distributed samples of the range_type Keyable PRFs may also be Seedable in which case they also have seed() member functions and corresponding constructors similar to those of Random Number Engines. Seeding a PRF is equivalent to setting its key to some value corresponding to the output of sseq.generate(). A PRF has a Countable Domain if its domain_type has member functions begin(), end(), and back() with semantics identical to that of boost::array<Uint, N> for some unsigned integral type Uint and some N. It must also have member functions domain_array_min() and domain_array_max() that specify the permissible domain values. Any array, da, whose members, da[i], satisfy: prf.domain_array_min() <= da[i] <= prf.domain_array_max[] must be "permissible". A PRF has an Integer Array Range if its range_type has member functions begin(), end(), and size() with semantics identical to boost::array<RangeInt, N>, for some integral type, RangeInt and constant N. It must also have static constexpr member functions, range_array_min() and range_array_max() that specify the subset of range values sampled by the PRF. For any sequence of permissible domain value, d1, d2, ..., the integers: prf(d1)[i], prf(d2)[i] must be statistically indistinguishable from independent uniformly distributed RangeInts from range_array_min() up to and including range_array_max(). If a PRF has a Countable Domain and an Integer Array Range, then: counter_based_urng<Prf> satisfies the requirements of a Uniform Random Number Generator. If, in addition, the PRF is Seedable, Streamable and Equality Comparable, then: counter_based_engine<Prf> satisfies the requirements of a Random Number Engine. A PRF is a Pseudo-Random Bijection if it is one-to-one and onto. I.e., if it has an inverse. It is not necessary for the inverse to have a practical implementation. It is sufficient that the inverse exist mathematically. A PRF is a Pseudo-Random Permutation if it is a Bijection and its domain_type is the same as its range_type. The four implemented PRFs are CopyAssignable, EqualityComparable, Streamable, Keyable, Seedable, Pseudo-Random Permutations with Integer Array ranges and Countable domains. Hence, they satisfy the requirements of counter_based_engine and counter_based_urng. Differences from Random123 -------------------------- This code is inspired by the Random123 library, but there are significant differences. New terminology: threefry<2, uint64_t> is a "Pseudo-Random Function" (PRF). PRFs take a key_type as a constructor argument, and are bijections on their ctr_type. Thus, instead of: typedef r123::Threefry2x64 r123_t; r123_t::ctr_type c; r123_t::key_type k r123_t::ctr_type r = r123_t(c, k) You now say: typedef boost::random::threefry<2, uint64_t> prf_t; prf_t::key_type k; prf_t myprf(k); prf_t::domain_type c; prf_t::range_type r = myprf(c); // Or alternatively, (more reminiscent of Random123) prf_t::range_type r2 = prf_t(k)(c); AESNI ----- Use of AESNI is tricky because we want both compile-time and runtime control over whether AESNI is used. The compile-time control is determined by BOOST_HAS_AESNI, which we assume will be set by some config file based on compiler-specific symbols (__AES__, __x86_64__, __ICC, __GNUC__) and possible user-overrides. But even if AESNI support is compiled in, we have to detect it and fall back to a software implementation at runtime if it's not available. The check requires either an asm with GCC-compatible compilers or an intrinsic with MSVC-compatible compilers. Endianness is another complication. The AESNI implementation only works on x86_64 platforms, so it is not endian-sensitive. In fact, it *defines* how multi-byte quantities are to be interpreted. In contrast, the software implementation has to be endian-aware. The current implementation has not been tested with other endians, and hence is almost certainly broken. And finally, the AESNI intrinsics are *very* fast. We don't want to weigh them down with lots of runtime checks. With AESNI enabled, the runtime overhead should cost no more than a single conditional at the top of operator()(c). The choice between hardware and software AES is controlled by a member data field, useAESNI, of the prf class. If hw AES is compiled in, useAESNI is initialized by a runtime check of the CPU capabilities. It can be changed with a mutator method. If hw AES is not compiled in, useAESNI is initialized false and it is an error to try to set it to true. In detail/aes_impl.hpp, we implement two classes: detail::hw128 detail::sw128 with a common interface that minimally meets the needs of AES and ARS. The interface includes +=, ^= constructors from array<uintW, N>, aesenc, and aeskeygenassist primitives, etc. The crucial functions in AES and ARS are then written with a template parameter that is assumed to provide the interface. An idiom like: #if BOOST_HAS_AESNI if( useAESNI ) method<detail::hw128>(args); else #endif method<detail::sw128>(args); gives the desired compile-time and runtime control.

7 10

[metagraph]
by Kitten, Nicholas 03 Feb '12

03 Feb '12

Hi Gordon (and whoever else is involved), What's the current status of metagraph / mpl_graph? I've been using msm::mpl_graph for error-checking/scheduling in a compile-time filter graph framework (similar to state machines, but focus is on data flow), and I'd certainly like to see more. As is, I've already implemented a topological sort based on the BFS which doesn't yield errors on cyclic graphs (which I'd be happy to contribute if you don't already have one), and I have some thoughts on improvement. I saw the BoostCon slides and the current state of the sandbox, and I was wondering if there's more code lurking out there somewhere, unchecked-in. Anyway, the single biggest flaw I see with the current BFS and DFS (and the BGL models they're based on) is that there is no way for the user to specify a termination condition in the base algorithm. It seems silly that an algorithm called "Search" can't end without traversing the whole connected component! Indeed, if there were simply an optional predicate determining whether a candidate vertex should be added to the stack/queue, I wouldn't have needed to write a separate algorithm for topo sort. The other thing is that not all of the listed visitor operations are called in the current implementations. Adding things like "initialize_vertex" and "non_tree_edge" to BFS is an easy fix. Thanks, Nick Kitten Software Engineer Center for Video Understanding Excellence ObjectVideo, Inc. http://www.objectvideo.com

3 6

[1.49.0] New libraries in 1.49.0?
by Beman Dawes 02 Feb '12

02 Feb '12

What are the new libraries in 1.49.0? --Thanks, --Beman

5 8

[interprocess] utf8 file names in memory mapped files
by Thorsten Ottosen 01 Feb '12

01 Feb '12

Hi Ion, It would be great if we could support utf8 encoded file names on windows too. I guess all it requires is a utility function that converts from utf8 to utf16 on windows. Such a function is avaiable in the windows API, and I can supply it. kind regards Thorsten

3 6

[1.49.0] Beta 1 release candidates available
by Beman Dawes 01 Feb '12

01 Feb '12

Release candidate files for 1.49.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers --PS: I downloaded the 7z version, and it build without errors on Win7/VC++ Express 2010 sp1

19 32

[1.49.0] Branches/release open for bug fixes and documentation updates
by Beman Dawes 01 Feb '12

01 Feb '12

branches/release is now open for bug fixes and doc updates, without need to ask for a release manager's permission. It will remain open until Monday, February 13th. The final release is scheduled for February 20th. The hope is that this somewhat longer beta period will allow time to fix more bugs that surface during the beta period. --Beman

4 4

[math_constants] Lots of "extra ';'" warnings
by sguazt 31 Jan '12

31 Jan '12

Hello, When compiling with GCC 4.6.2 with flags "-Wall -Wextra -ansi -pedantic", I get the following warnings: boost/math/constants/constants.hpp:211:199: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:212:200: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:213:204: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:214:205: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:215:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:216:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:217:205: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:218:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:219:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:220:206: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:221:207: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:222:211: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:223:197: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:224:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:225:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:226:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:227:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:228:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:229:212: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:230:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:231:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:232:214: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:233:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:234:207: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:235:206: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:236:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:237:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:238:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:239:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:240:214: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:241:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:242:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:243:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:244:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:245:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:246:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:247:196: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:248:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:249:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:250:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:251:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:252:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:253:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:254:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:255:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:256:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:257:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:258:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:259:198: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:260:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:261:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:262:200: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:263:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:264:204: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:265:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:266:205: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:267:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:268:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:269:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:270:217: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:271:212: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:272:212: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:273:219: warning: extra ‘;’ [-pedantic] Could you fix them? Thank you very much, Best, -- Marco

1 0

[strings][unicode] Proposals for Improved String Interoperability in a Unicode World
by Beman Dawes 31 Jan '12

31 Jan '12

Beman.github.com/string-interoperability/interop_white_paper.html describes Boost components intended to ease string interoperability in general and Unicode string interoperability in particular. These proposals are the Boost version of the TR2 proposals made in N3336, Adapting Standard Library Strings and I/O to a Unicode World. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3336.html. I'm very interested in hearing comments about either the Boost or the TR2 proposal. Are these useful additions? Is there a better way to achieve the same easy interoperability goals? Where is the best home for the Boost proposals? A separate library? Part of some existing library? Are these proposals orthogonal to the need for deeper Unicode functionality, such as Mathias Gaunard's Unicode components? --Beman

7 27

[c++TR2] N3334, Proposing array_ref<T> and string_ref
by Beman Dawes 31 Jan '12

31 Jan '12

On Sat, Jan 28, 2012 at 8:12 PM, Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > On 01/28/2012 05:46 PM, Beman Dawes wrote: >> >> Beman.github.com/string-interoperability/interop_white_paper.html >> describes Boost components intended to ease string interoperability in >> general and Unicode string interoperability in particular. >> >> These proposals are the Boost version of the TR2 proposals made in >> N3336, Adapting Standard Library Strings and I/O to a Unicode World. >> See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3336.html. >> >> I'm very interested in hearing comments about either the Boost or the >> TR2 proposal. Are these useful additions? Is there a better way to >> achieve the same easy interoperability goals? > > > I think you should consider the points being made in N3334. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html While this proposal isn't from Boost, it impacts interests of Boost developers enough that I think it is worth discussing here as a separate topic. Mathias continues: > While that proposal is in my opinion not good enough, it raises an important > issue that is often present with std::string-based or similar designs. > > A function that takes a std::string, or a boost::filesystem::path for that > matter, necessarily causes the [caller] to copy the data into a heap-allocated > buffer, even if there is no need to. Some std library string implementations avoid the heap allocation for small strings, but still there is an unnecessary copy happening even in those implementations. Your point is well taken and I've often worried about it with boost::filesystem::path. > Use of the range concept would solve that issue, but then that requires > making the function a template. A type-erased range would be possible, but > that has significant performance overhead. > a string_ref or path_ref is maybe the lesser evil. One of my blink reactions is that array_ref<T> and basic_string_ref<charT, traits> are range generators and I was a bit surprised to see the implementation was a pointer and length rather than two pointers. Or better yet, two iterators or an explicit range component. With iterators, a basic_string_ref could do encoding conversions on-the-fly without need of temporary strings. But I have no idea if that is workable or actually is better. What do other Boosters think? --Beman --Beman

5 7

[conversion] Lot of 'long long' warnings
by sguazt 31 Jan '12

31 Jan '12

Hello, When compiling with GCC 4.6.2 with flags '-Wall -Wextra -ansi -pedantic', I get the following warnings concerning the use of the 'long long' type under the ISO C++98: boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:16:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:21:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:28:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:33:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:40:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:45:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:52:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:57:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:64:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:69:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:76:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:81:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:88:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:93:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:100:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:105:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:112:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:117:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:124:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:129:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:136:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:141:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:148:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:153:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:160:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:165:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:172:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:177:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:184:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:189:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:196:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:201:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:208:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:213:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:220:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:225:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:232:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:237:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:244:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:249:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:256:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:261:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:268:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:273:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:280:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:285:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:292:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:297:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:303:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:304:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:309:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:315:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:316:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:321:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:327:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:328:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:333:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:339:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:340:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:345:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] Could you fix them? Thank you very much. Best, -- Marco

3 3

[context] Boost.Context library accepted
by Giovanni Piero Deretta 31 Jan '12

31 Jan '12

Hi All, The mini-review of the boost.context library from Oliver Kowalke ended two weeks ago. After a slow start, three reviews were eventually submitted, all positive. For a mini-review, I think this is enough and, as the review manager, I'm happy to announce that Boost.Context is accepted as an official boost library. Congratulations to Oliver for this achievement and thanks for submitting an useful library to Boost. Most of the review discussions were around the quality of the documentation and some misunderstanding of some details of the library. While the documentation has greatly improved since the first review, I think that it can be still improved. I encourage Oliver to seek the help of some native English speaker to help copy edit the docs. Finally I would like to thanks everybody that participated in the review discussions and in particular those that submitted reviews. regards, -- Giovanni Deretta,

2 1

Requesting a review of Metaparse
by Abel Sinkovics 31 Jan '12

31 Jan '12

Hi, I've created a version of Metaparse that depends on the Boost libraries only. I request this version of Metaparse be placed in the queue for formal review. The zipped source code can be found here: http://abel.web.elte.hu/metaparse/metaparse.zip The documentation can be found here: http://abel.web.elte.hu/metaparse/metaparse The library has been tested on the following compilers: - GCC 4.6 (with and without -std=c++0x) - GCC 3.4 - Clang 2.9 - Visual C++ 10 A quick summary: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Regards, Abel

7 16

My non-system GCC doesn't link programs under b2
by Daryle Walker 30 Jan '12

30 Jan '12

I'm still using my 2002 PowerPC/G4 Mac with Mac OS X 10.4 (Tiger). I loaded GCC 4.6 (with multiprocessor options) onto it with MacPorts. I have a "user-config.jam" in my home folder like: //===using xsltproc : /opt/local/bin/xsltproc ; using boostbook : /opt/local/share/xsl/docbook-xsl/ : /opt/local/share/xml/docbook/4.2 ; using doxygen ; using darwin ;using gcc : 4.6 : g++-mp-4.6 : <cxxflags>-std=c++0x <cxxflags>-pthread ;//=== I've tested GCC-4.6 (with C++11 active) with a "Hello World!" program, so I know it works with single-file programs. I wanted to test "base_from_member" (part of Boost.Utility) and it worked with the default "darwin" target. (I ran "b2" in "BOOST_ROOT/libs/utility/test".) However, running "b2 toolset=gcc-4.6" ended in errors like: //===common.mkdir ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6common.mkdir ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debuggcc.compile.c++ ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test.o../base_from_member_test.cpp: In constructor 'bad_class::bad_class()':../base_from_member_test.cpp:129:21: warning: 'bad_class::x_' will be initialized after [-Wreorder]../base_from_member_test.cpp:510:39: warning: base 'base_class' [-Wreorder]../base_from_member_test.cpp:507:1: warning: when initialized here [-Wreorder]gcc.link ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test/usr/bin/ld: unknown flag: --start-groupcollect2: ld returned 1 exit status "g++-mp-4.6" -o "../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test" -Wl,--start-group "../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g ...failed gcc.link ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test......skipped <p../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug>base_from_member_test.run for lack of <p../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug>base_from_member_test......failed updating 20 targets......skipped 40 targets......updated 126 targets...//=== GCC-4.6 compiles each C++ file into an object file just fine. The problem happens when linking various object and library files into an executable; whichever linker gets called (the system linker?) chokes on a "--start-group" flag. When I first started writing this message, I thought the problem was GCC-4.6 being too new for the linker, but maybe we have to tweak something in our Jam files instead. (Could it be the fact I downloaded the multiprocessor variant of GCC-4.6?) BTW, how do I specify that I only want to try out the base_from_member test without trying to build all other tests in the directory? Daryle W.

4 4

[thread] Can't use boost/thread/mutex.hpp without boost_system
by Artyom Beilis 30 Jan '12

30 Jan '12

Hello, The Boost.Thread version in trunk does not allow to use simple mutex as it was possible before: #include <boost/thread/mutex.hpp> #include <iostream> int main() { boost::mutex l; { boost::unique_lock<boost::mutex> g(l); std::cout << "Test" << std::endl; } } Was working fine without linking with 1.48 and 1.46 but now it fails with current trunk version requiring dependency on Boost.System. It breaks some code and breaks at least Boost.Locale. Is this change intentional or a bug? If it is intentional I'd like to know to fix Boost.Locale if not then is it possible to fix it. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

9 30

Re: [boost] [Boost-users] numeric_cast_traits/cstdint: request for fix in boost1.49
by John Maddock 30 Jan '12

30 Jan '12

>Currently HPUX/acc compiler fails in boost 1.48, because boost::int8_t was >being interpreted as a char, This causes duplicate class definition >in the file >./boost/numeric/conversion/detail/preprocessed/numeric_cast_traits.hpp >and hence many of compiled boost libs fail. Thanks for raising this on the list, I just posted these comments to the Trac ticket: "IMO this is the wrong fix: our code should make no assumptions about the actual type of uintXX_t etc. IMO the preprocessed headers are just plain wrong - you can't mix concrete types (char short etc) with typedefs (intXX_t) because you're just asking for problems with duplicate specializations. It has to be all real types throughout. BTW in addition to the two platforms mentioned above, this is also broken for Sun on Linux. Reassigning to the person who made these changes..." Not sure if we can fix this for 1.49, but you're right, it is a high priority. Hopefully Brandon Kohn is reading this as he made those changes? John.

5 9

[Boost.Asio] Asio is using Boost.Chrono for 1.49?
by Christian Hägele 30 Jan '12

30 Jan '12

Hello, as I looked through the changes for Boost.Asio with boost 1.49 I noticed that it looks like Boost.Chrono's steady_clock is used for timers (when std::chrono is not available). First of all that very nice, because steady_clock is not affected by change of the system-time. However I think there is a major problem on windows. On windows there are some problems with QueryPerformancecoutner in multi-processor systems (http://support.microsoft.com/kb/274323) There is also a comment in boost/chrono/system_clocks.hpp about this issue and no real solution provided. Is that problem solved by now? If not will the better choice be to stick with the old system-time implementation until std::chrono is supported on MSVC? Or is this problem rather a minor problem and can be ignored? Regards, Christian

1 0

[bjam] copy a file
by lcaminiti 30 Jan '12

30 Jan '12

Hello all, I'd have a Jamfile that has a "doc" rule to build documentation `bjam doc`. I'd like to program another rule "config_doc" inside the Jamfile that does the following: bjam config_doc: 1) Copy the file /etc/config.txt to ./ 2) Copy the file ./src/config.txt to /etc/ 3) Run the doc rule 4) Copy the file ./config.txt into /etc/ Where ./ is the current directory from where I'm running bjam. Ideally, I'd like 4) to be executed even if 3) fails. Is there a way to do this? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-bjam-copy-a-file-tp4321537p4321537… Sent from the Boost - Dev mailing list archive at Nabble.com.

8 15