- Boost - lists.preview.boost.org

[numeric][ublas] please add vector constructor from boost::range
by Jochen Wilhelmy 20 Jul '12

20 Jul '12

Hi! is it possible to add a constructor for ublas::vector from boost::range? this would it make easier to construct from pain data (e.g. float*). something like boost::numeric::ublas::vector<float> v(boost::iterator_range<const float*>(myDataBegin, myDataEnd)); -Jochen

4 3

[optional] reduce need for operator ==
by Jochen Wilhelmy 20 Jul '12

20 Jul '12

Hi! currently boost::optional<Type> requires an operator == for Type. If I only want to check if the optional is present or not, then this is not necessary. e.g. struct Foo {int i;}; boost::optional<Foo> foo; if (foo == boost::none) ... is it possible to change this? for example by template<class T> inline bool operator == ( optional<T> const& x, none_t ) { return !x; } -Jochen

3 2

[TypeErasure] Composing Concepts & some notes
by Fabio Fracassi 20 Jul '12

20 Jul '12

Hi Steven, I am going through the documentation and simultaneously try out some things that weren't immediately obvious to me. When I came to the paragraph about composing concepts the last sentence "We can even specialize concept_interface for it." tripped me up. My thought was "but do I have to? and how do composed concepts interact with manually composed any's?" so I gave it a try: I used your push_back concept and defined a size concept like this: template<class C> struct size { static size_t apply(C& cont) { return cont.size(); } }; namespace boost { namespace type_erasure { template<class C, class Base> struct concept_interface< ::size<C>, Base, C> : Base { size_t size() { return call(::size<C>(), *this); } }; } } which works fine: std::vector<int> vec; typedef any<push_back<_self, int>, _self&> any_push_back; any_push_back pb(vec); pb.push_back(10); pb.push_back(2); typedef any<size<_self>, _self&> any_size; any_size s(vec); std::cout << "Size = " << s.size() << std::endl; Now I wanted to try composition first manually: typedef any< mpl::vector< push_back<_self, int>, size<_self> >, _self& > any_manual_vecconcept; any_manual_vecconcept alvec(vec); alvec.push_back(13); alvec.push_back(11); std::cout << "Size = " << alvec.size() << std::endl; and then via "named composition": template<class T, class C> struct vecconcept : mpl::vector< push_back<T, C>, size<T> > {}; typedef any<vecconcept<_self, int>, _self&> any_vecconcept; any_vecconcept acvec(vec); acvec.push_back(15); acvec.push_back(17); std::cout << "Size = " << acvec.size() << std::endl; great everything works as expected, and no, I did not have to define a concept_interface for the composite interface. Now the first question is why would I want to? now the main reason for the exercise was how do these interact with each other and while I am at it how do they interact with the concepts they are composed of? Well I can freely interact as I hoped: any_vecconcept acvec2(alvec); any_manual_vecconcept alvec2(acvec); any_push_back pb3(alvec); any_push_back pb4(acvec); any_size s2(alvec); any_size s3(acvec); This is great! I might have missed it in the documentation, but I think this is really an important feature that deserves special mention. Now I gather that there is no way to do the opposite, something along the lines of any_vecconcept acvec3 = dynamic_any_cast<any_vecconcept>(s3); Well over the next days I will dive a bit deeper into the internals to see if implementing such a feature would be feasible. (because I need it before I could replace my current solution with type erasure) Steven, let me finish by saying thank you for the great work. regards Fabio

2 2

[pool] Calling all library designers: The future of Boost.Pool???
by John Maddock 19 Jul '12

19 Jul '12

As one of the last people to try and do any maintenance of Boost.Pool I feel I should try and start some discussion here on it's future. First off some random thoughts based on my last experiences with this library: * It should be simple, but it's confusing. In particular the difference between ordered and unordered pools is not particularly intuitive, but IMO the distinction between the various components, and what should be used where is also poor. * I believe the decision to support both ordered and unordered pools in the same interface was a mistake. At the very least it's potentially error prone in use, but it's also inefficient. It looks to me that this, along with the allocators provided, were a classic case of feature creep post-review. I'm sure they sounded like good ideas during the review, but in practice a smaller more tightly focused library might actually be better. * It's not clear that the claimed performance improvements are actually there in practice (any more). This is partly due to compiler and std lib improvements, partly due to feature creep in Boost.Pool. Some bug fixes have had a negative effect too - however needed they may have been for correctness. * Many of the existing bug reports were deliberately left "in limbo" because there was no obvious/easy way to fix them without compromising Boost.Pool's core mission (providing fixed size blocks of memory really fast). * There have been many changes to the standard, compiler technology, and to Boost's best practices since the library was designed, many of which would result in a different design today, but also different requirements today (per instance allocators in containers for example). * In no way do I want to be lumbered with maintaining Boost.Pool and in any case I don't believe it's really fit for purpose any more [1]. So..... in an ideal world, I'd like someone to step up to the plate and design it's replacement.... yes a whole new Pool2. Off the top of my head, here's my wish list: * There should be a very small, very focused (i.e. fast) core that provides fixed sized blocks of memory. Nothing more. * Thread synchronization when needed (template param?) should be via lockfree programming wherever possible. Indeed a simple pool like this, is pretty much the poster child for lock-free-programming. And of course we have Boost.Lockfree now. * There should probably be a heap implementation for variable sized allocation requests. I'm assuming that this can't be done lockfree(?). * Allocators: both singleton and stateful allocators should be provided (templated on pool type?). But there's a trick here: many containers only allocate fixed size blocks, but we have no way of knowing what that size is upfront at compile time. Connecting the allocation request to the correct pool interface in an efficient manner is pretty tricky here, especially if 99% of allocations are of fixed sized, but there are a few odd-sized control blocks also allocated. In any case, all allocations should come from the same underlying block of memory, even if they're for different types/sizes. * Both pools and allocators, should be able to accept a single fixed sized block of memory (from wherever) and divide it up to clients. A good example for this use case is an arena-allocator: a stateful allocator whose memory all comes from the stack, no thread synchronization required. Containers using such types can be blisteringly fast compared to regular allocators, particularly when using a scoped container for just a few manipulations. Ideal for use with C++11 containers or Boost.Container. Hopefully others will chime in here with their requirements as well. Cheers all, John. 1) This doesn't preclude applying *trivial* fixes to Boost.Pool, but I genuinely believe that big changes are more likely to be counterproductive at this point.

11 19

[website] Build & link field in library list
by Daniel James 19 Jul '12

19 Jul '12

Hi, In the library list (http://www.boost.org/doc/libs/) I don't think the 'build & link' field is very accurate. There's a recent bug report about pool, which apparently isn't header only. I suspect it's wrong for some other libraries as well, and for some libraries the situation is a bit more complicated. So, I'm thinking about removing it. Incorrect and misleading information can be worse than no information at all. Does anyone have an attachment to it? Daniel

1 0

[TypeErasure] assignment operator of any references
by Vicente J. Botet Escriba 19 Jul '12

19 Jul '12

Hi, The References section constains this example: int i, j; any<typeid_<>, _self&> x(i), y(j); x = y; // error The following basic c++ code int i=1, j=0; int& x(i); int& y(j); x = y; // [1] works and the expected value of x after [1] is 0. Which concept requirements should I add to make the following work? assignable? int i, j; any<mpl::vector<typeid_<>, ...>, _self&> x(i), y(j); x = y; // no error Best, Vicente

2 3

How to find all paths with a length in a certain range
by J Birch 18 Jul '12

18 Jul '12

I am fairly new to Boost, and not the greatest at C++, but I do have a bit of experience in dealing with graphs in other languages. We currently have some very ugly and inefficient code that effectively builds up a graph structure (DAG), and must calculate all paths with a length between a certain range, say 3-7. I have seen the question asked a few times via Google, but I have seen no solution. I have been tinkering around with different examples, but have yet to come up with anything useful. Would anyone be able to point me in the right direction? Thanks! Birch

3 3

Merging to release
by Marshall Clow 18 Jul '12

18 Jul '12

The deadline for bug fixes for 1.51 is tomorrow; and I'd like to merge the changes I made to the following libraries to release: * Config - reorganized the c++11 macros * Unordered - changed #ifdefs to use non-deprecated macros * functional/hash - changed #ifdefs to use non-deprecated macros * Random - changed #ifdefs to use non-deprecated macros * Regex - changed #ifdefs to use non-deprecated macros * Math - changed #ifdefs to use non-deprecated macros I've been watching the test results; and it turns out I broke two of the C++11 tests, which only affects people running the tests on C++11 compilers. I fixed those this morning. Any objections? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

9 11

Re: [boost] Boost.config limits_test testcase and qnan checks
by Matthew Markland 18 Jul '12

18 Jul '12

Extra text elided below: > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost- > bounces(a)lists.boost.org] On Behalf Of boost-request(a)lists.boost.org > Sent: Friday, July 13, 2012 10:51 PM > To: boost(a)lists.boost.org > Subject: Boost Digest, Vol 3701, Issue 4 >----- <elided> > Message: 5 > Date: Fri, 13 Jul 2012 18:07:45 +0000 > From: Thomas Klimpel <Thomas.Klimpel(a)synopsys.com> > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Subject: Re: [boost] Boost.config limits_test testcase and qnan > checks. > Message-ID: > <4468C9C2AE594745A32DC93C799A224A01D0FB(a)DE02WEMBX2.inte > rnal.synopsys.com> > > Content-Type: text/plain; charset="us-ascii" > <elided> MARKLAND> My question is whether it is valid to test the qnan behavior when a MARKLAND> platform MARKLAND> > does not claim compliance? > > I wonder how you measure "claim compliance"? I once had a long debug > session with gcc-4.5.2 before I found out that the builtin "is_nan" was > returning wrong results. Isn't compiling the code that uses "is_nan" without > warning also some sort of "compliance claim"? I know you are probably > referring to "numeric_limits<double>::is_iec559", but on which floating point > functionality can I still rely as a programmer if (is_iec559 == false)? > > Regards, > Thomas I've now been trying to come up with a good answer to this for days and have yet to get there. So I'm going to just comment and see if the discussion continues. These are my interpretations and should not be construed as the opinion of my employer. In the case of this particular test, from a language perspective, I think the check for is_iec559 makes sense. The part of the test in question is testing a behavior that is only defined for certain if the platform is using an IEEE compliant implementation. Now this doesn't mean that it won't work for a platform that sets is_iec559() to false, but to me it is only guaranteed if is_iec559() is true. As for what you can rely on if is_iec559() is false, that is a good question. Most of the items in numeric_limits<> appear to require explicit checks for availability if is_iec559() is false. My readings of the Standards (C/C++) seem to show them to be silent on what happens with a function like isnan() if is_iec559() is false. Most of what I've seen on the web is that these functions are of dubious usefulness due to optimizations performed. Clearly one would like to expect that if the compiler is being used at an optimization level that breaks floating-point compliance then is_iec559() would be set to false, but from what I've read that isn't a safe expectation. I guess you're at the mercy of your compiler vendor to describe their levels of support and what these functions may mean. Does anyone else have insight into this situation? Matt

3 2

conversion review report
by Gordon Woodhull 18 Jul '12

18 Jul '12

Hi Vicente, all, Profuse apologies for the long delay in writing this report. Cheers, Gordon Report on Boost Conversion Library Review, August 20-29, 2011. I want to thank Vicente Botet Escriba for submitting the Conversion library for review and for his general good nature in receiving criticism and alternate designs. The Conversion library presents a general framework for plugging in conversion operations between arbitrary types, providing a consistent interface for type-to-type conversions. The library is unfortunately rejected. During the review, there were two votes for acceptance and two against, and some interesting conversation from about a dozen participants. The major reason the library can't be accepted in its current form is that there was near consensus that there is no universal conversion domain, especially when the source or destination type might be a string. Much of the review focused on possible One Definition Rule (ODR) violations, which are a consequence of having a universal customization point using template specializations or function overloads. Many solutions were offered, which will make up the second part of this report, "How to Avoid Universality." I. Concerns about the library Conversions Are Not Generic? While some reviewers didn't see the need for a generic conversion library (and I was a little surprised at the vehemence of their opinions), I don't see this in itself as a reason to reject the library. The library's stated purpose is to provide a common interface for general type <-> type conversions, like lexical_cast does for string <-> type conversions. However, it was interesting that seemingly no one could come up with applications of truly generic conversion, although Jeffrey Lee Hellrung and Antony Polukhin alluded to their existence. Also, some reviewers pointed out that you often need to choose what kind of conversion to do, and a generic library can get in the way here. Strings are the most obvious example: if you are converting from a string representing a binary value it would not work to use a decimal converter. Antony Polukhin pointed out a more subtle example: "lexical_cast<char>(1) and numeric_cast<char>(1) will produce different output." Jeff Hellrung summed this point up nicely: "I think it's certainly possible for different clients using the same generic component to want different conversion implementations for a given pair of types, and that point, Boost.Conversion's universally-defined conversion implementations become useless. One wants the conversion operation to be parametrized as well as the types involved in the conversion." Multi-Client Specialization Concerns Leaving aside possible ODR violations, which we'll return to in Part II, some reviewers questioned the scalability of using template specialization and overloads when many clients (i.e. independent headers) may be customizing the behavior. Vladimir Batov claimed that a system which allows partial specializations on both Source and Target can't be made to work generally. Jeroen Habraken said SFINAE/enable_if "does make code fragile". I'm not clear if these conversations were resolved (or resolvable ;). Non-Generic Solutions Some reviewers objected that conversions should just be defined within individual libraries, but of course this begs the question (as came up recently on the ML between DateTime and Chrono), "which library should house the conversions?" Others (such as Phil Endecott) thought that simple c-style functions such as rgb_to_cmyk() were more explicit and direct. Why is this so complex? Kevlin Henney, initially excited about a general solution to the problem which lexical_cast first set out, commented on the documentation: "Based on casual reading, it feels a little more complex and requires a higher-entry level of knowledge than would be appropriate for many of the people who actually need this functionality." II. How to Avoid Universality One of the positive results of this review was a small catalog of alternatives to a universal customization point involving template specialization or overloaded functions. a. Avoid the Problem In the strictest sense, any library which allows either kind of universal customization can be prone to ODR violations. But many reviewers particularly thought that a customization point involving two UDTs was especially dangerous. To his credit, Vicente was very up-front about the limitations of his design, and attempted to formulate rules for how the library could be used safely. In the documentation, he suggests (IIUC) that header-only libraries could use generic conversions as long as they don't define them, or define them as long as they don't use them. http://tinyurl.com/cmbgyfk b. Inherited tags John Bytheway suggested a tag-dispatch system where conversions are tagged with their source library, and any library which depends on conversions from two libraries would define a tag which inherits from the tags of both libraries. Thus ODR violations are avoided at the expense of having to specify an extra tag (effectively a sort of global conversion domain). http://lists.boost.org/Archives/boost/2011/08/184836.php c. Conversion Domains and Overloaded Function Objects Going on the consensus that there is no universal conversion domain, your humble review manager suggested a metaprogramming solution that defines conversion domain objects which combine a set of conversions within an object. http://lists.boost.org/Archives/boost/2011/08/185259.php A more general solution would be to create an overloaded polymorphic function object, much like a polymorphic-source version of Lorenzo Caminiti's OverloadedFunction library (http://tinyurl.com/72nolyj) However, I have been warned (by Daveed Vandevoorde) that the rules for function overloading are too dangerously complicated to implement in a metaprogram. d. Boost.Dispatch Matthias Gaunard announced that he is working on a library particularly to "solve the problem of specializing a function template for a category of types with best-match selection." http://lists.boost.org/Archives/boost/2011/08/185286.php e. Abuse of Unnamed Namespaces Emil Dotchevski suggested that "It might be possible to abuse unnamed namespaces to avoid violating ODR". I'm not clear if this was a serious suggestion as it wasn't spelled out. :) f. GIL's solution (?) Christian Henning wrote: "GIL has such functionality. I like their way of structuring conversion." However, I was not able to find a description of this mechanism for the report. Thanks to everyone who participated in the review!

2 1

[Pool] Patches
by DUPUIS Etienne 17 Jul '12

17 Jul '12

Greetings, https://svn.boost.org/svn/boost/sandbox/pool at revision 79460 contains a solution for tickets #3789, #5902, #6561, #6610, #6701, #6718, #6865 and #6867. Related test cases for each ticket are also present. By the way, the Pool tests fail in the trunk; a missing dependency on Boost.System, which I added to the JamFile in sand box. https://svn.boost.org/svn/boost/sandbox/pool at revision 79460 does not contain any other new features or modifications other than those related to the above tickets. As Boost.Pool currently has no maintainer and is thus orphaned, and also since I am leaving the mailing list, I reassigned these tickets to John Maddock since he was the last to commit code changes into Boost.Pool. Regards, Étienne Dupuis Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.

2 1

[mpl] std::integral_constant support?
by Eric Niebler 17 Jul '12

17 Jul '12

The following reasonable-seeming use of mpl::plus doesn't compile: #include <utility> #include <boost/mpl/plus.hpp> typedef std::integral_constant<int, 1> one; typedef boost::mpl::plus<one, one>::type two; That's because mpl only works with its own integral constant wrappers, not the standard one. That seems unfortunate to me. Is there any interest in supporting this? Here's the error (from clang trunk with glibc++): 1> In file included from main.cpp:2: 1> In file included from /home/Eric/boost/org/trunk/boost/mpl/plus.hpp:19: 1> In file included from /home/Eric/boost/org/trunk/boost/mpl/aux_/arithmetic_op.hpp:34: 1> In file included from /home/Eric/boost/org/trunk/boost/mpl/aux_/include_preprocessed.hpp:37: 1> /home/Eric/boost/org/trunk/boost/mpl/aux_/preprocessed/gcc/plus.hpp:60:25: error: no type named 'tag' in 'std::integral_constant<int, 1>' 1> typedef typename T::tag type; 1> ~~~~~~~~~~~~^~~ 1> /home/Eric/boost/org/trunk/boost/mpl/aux_/preprocessed/gcc/plus.hpp:111:20: note: in instantiation of template class 'boost::mpl::plus_tag<std::integral_constant<int, 1> >' requested here 1> typename plus_tag<N1>::type 1> ^ -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[Memory][SmartPtr][Interprocess] Is there an interest in a Boost library more or less c++11 compliant?
by Vicente J. Botet Escriba 16 Jul '12

16 Jul '12

Hi, Boost has a lot of pieces of the c++11 header <memory>, shared_ptr, weak_ptr , ... in Boost.SmartPtr, unique_ptr, allocator argument tag, uses_allocator ... in Boost.Interprocess. Other are already in the C++03 <memory> header. Others are missing, as pointer_traits, default_delete, ... I would like we complete all these features and move them to a Boost.Memory library smoothly (something like the Boost.Utility). As these are standard features, I propose to use directly the boost namespace for them. boost memory.hpp memory pointer_traits_hpp ... unique_ptr.hpp shared_ptr.hpp weak_ptr.hpp ... What do you think? Best, Vicente

2 1

[type_traits] has_equal_to< std::vector<T> > always true_
by lcaminiti 15 Jul '12

15 Jul '12

-- View this message in context: http://boost.2283326.n4.nabble.com/boost-type-traits-has-equal-to-std-vecto… Sent from the Boost - Dev mailing list archive at Nabble.com.

11 33

[1.50.0] PDF documentation available
by John Maddock 15 Jul '12

15 Jul '12

With apologies for being so late with these.... The PDF build of Boost's documentation for 1.50 is available from the usual SF site: https://sourceforge.net/projects/boost/files/boost-docs/1.50/ John.

2 1

[atomic] trunk doesn't build with VC++
by Luke Elliott 14 Jul '12

14 Jul '12

compile-c-c++ ..\..\..\bin.v2\libs\atomic\build\msvc-9.0\debug\threading-multi\lockpool.obj lockpool.cpp D:\dev\checkouts\boost-trunk\boost/atomic/detail/interlocked.hpp(125) : error C2039: 'platform_cmpxchg32' : is not a member of 'boost::atomics::detail' D:\dev\checkouts\boost-trunk\boost/atomic/detail/interlocked.hpp(125) : error C3861: 'platform_cmpxchg32': identifier not found D:\dev\checkouts\boost-trunk\boost/atomic/detail/interlocked.hpp(127) : warning C4800: 'boost::uint32_t' : forcing value to bool 'true' or 'false' (performance warning) Should it be using platform_cmpxchg32_strong at line 125 of interlocked.hpp? And return (0 != expected) (or something) on line 127 to clean up the warning? Best regards Luke Elliott.

1 0

Clang Darwin trunk Cray 8.0 and max_digits10 support - problem in config?
by Paul A. Bristow 14 Jul '12

14 Jul '12

I note that the test of ztest_max_digits10 and zztest_max_digits10 in http://www.boost.org/development/tests/trunk/developer/math.html both fail for these platforms. ztest_max_digits10 tests of native std::numeric_limits<>::max_digits10 is supported. zztest_max_digits10 test if BOOST_NO_NUMERIC_LIMITS_LOWEST is a proxy to signal support. where using std::numeric_limits<>::max_digits10 should be possible using BOOST_NO_NUMERIC_LIMITS_LOWEST as a proxy for Clang the messages are In file included from ../libs/math/test/zztest_max_digits10.cpp:27: In file included from ../boost/config.hpp:40: ../boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found # include <cstddef> In file included from ../libs/math/test/ztest_max_digits10.cpp:27: In file included from ../boost/config.hpp:40: ../boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found or for Cray CC-1353 crayc++: INTERNAL File = /opt/gcc/4.4.4/snos/include/g++/bits/move.h, Line = 34 CIF Error #include <cstddef> ^ This appears to be a problem in the config - a missing include. Suggestions? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 24

[asio] boost::asio::read with empty input vector leads to an infinite loop
by Michael Kochetkov 13 Jul '12

13 Jul '12

Hello, In the code bellow I have forgotten to set the input vector (request) size. Is the code really supposed to react as an infinite loop (no errors, length is always 0, boost::asio::read returns immediately) or such behavior is a defect? for (;;) { std::vector<uint8_t> request; boost::system::error_code error; size_t length = boost::asio::read(sock, boost::asio::buffer(request), error); if (error == boost::asio::error::eof) break; else if (error) throw my_exception(L"Socket error"); ... } Thank you in advance, -- Michael Kochetkov

4 5

[filesystem] 1.49 linking with c++0x
by Daniel Larimer 13 Jul '12

13 Jul '12

Given: // cp.cpp #include <boost/filesystem.hpp> int main( int argc, char** argv ) { if( argc < 3 ) return -1; boost::filesystem::copy_file( argv[1], argv[2] ); return 0; } g++ -o cp cp.cpp -std=c++0x -I /usr/local/include /usr/local/lib/libboost_filesystem.a /usr/local/lib/libboost_system.a Undefined symbols for architecture x86_64: "boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option, boost::system::error_code*)", referenced from: boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&) in ccUAyvBD.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status If I remove the -std=c++0x flag then it links just fine. g++ --version g++ (MacPorts gcc47 4.7.0_3) 4.7.0 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Dan

6 9

Boost.config limits_test testcase and qnan checks.
by Matthew Markland 13 Jul '12

13 Jul '12

First an introduction; my name is Matt Markland and I support the Cray Compiling Environment (CCE) C/C++ compiler for Cray, Inc. We (Cray) are in the process of improving our Boost support and currently have an intern doing some work for us on this path. While working on Boost.config, he has run into a testcase failure with the limits_test function test_float_limits(). With default options, CCE fails the qnan tests due to the fact that we do not conform to the IEEE specification. CCE is a little different here in that by default it runs at a higher optimization level then other compilers. Gcc will fail this portion of the test if you compile with optimization on and -ffast-math. My question is whether it is valid to test the qnan behavior when a platform does not claim compliance? It seems to me that these checks should be wrapped in an is_iec559 check. Thoughts? Thanks for your time! Matt ---- Matthew Markland Compiler Front-End and Libraries C/C++ Front-End markland(a)cray.com 651-605-9186

3 2

Update request to Boost Discussion Policy maintainers
by Mateusz Loskot 13 Jul '12

13 Jul '12

Folks, May I request to update the "Effective Posting" section of the policy at: http://www.boost.org/community/policy.html#effective adding the following new sub-section as first: """ Use Sensible Subject Please make sure that your postings have a meaningful subject line that is related to the contents of your mail. Many people use this to help determine which posts to read and which to ignore when they're operating under time constraints. """ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Review Wizard Status Report for July 2012
by Ronald Garcia 13 Jul '12

13 Jul '12

============================================== Review Wizard Status Report for July 2012 ============================================== News ==== 1. Multiprecision Arithmetic Reviewed 2. Boost 1.50.0 Released. New Libraries: 1) Algorithm 2) Functional/OverloadedFunction 3) LocalFunction 4) Utility/IdentityType Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Conversion - reviewed August 2011; review manager: Gordon Woodhull. * Predef - reviewed February 2012; review manager: Joel Falcou. * Multiprecision - reviewed June 2012; review manager: Jeffrey Hellrung The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak. * GIL.IO - accepted January 2011; author: Christian Henning. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Atomic - accepted July 2011; author Helge Bahmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. * Lockfree - accepted August 2011; author: Tim Blechmann. * Context - accepted January 2012; author: Oliver Kowalke. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Endian - accepted provisionally November 2011; author: Beman Dawes. * Log - accepted provisionally March 2010; author: Andrey Semashev. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Type Erasure * Range Extensions * Contract * Nowide (M) * ODEint (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: https://github.com/boost-vault/Miscellaneous/blob/master/Pimpl.zip :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: This library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: 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). Polygon: Voronoi Extensions --------------------------- :Author: Andril Sydorchuk :Review Manager: Lucanus Simonson :Download: http://svn.boost.org/svn/boost/sandbox/gtl/ :Description: This library extends Boost.Polygon with the following features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). Coroutine --------- :Author: Oliver Kowalke :Review Manager: Hartmut Kaiser :Download: http://gitorious.org/boost-dev/boost-dev/archive-tarball/coroutine :Description: This library is an implementation of coroutines and generators using Boost.Context. Type Erasure ------------ :Author: Steven Watanabe :Review Manager: Lorenzo Caminiti :Download: http://sourceforge.net/projects/steven-watanabe.u/files/ :Description: The TypeErasure library is a generalization of boost::any and boost::function. It allows easy composition of arbitrary type erased operators. Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Contract -------- :Author: Lorenzo Caminiti :Review Manager: Dave Abrahams :Download: http://sourceforge.net/projects/contractpp/files/latest/download :Description: This library implements Contract Programming for the C++ programming language (see the end of this email). In addition, the library implements virtual specifiers (final, override, and new, see C++11), concept checking, and named parameters. This library is implemented for the C++03 standard and it does not require C++11. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. ODEint ------ :Author: Karsten Ahnert and Mario Mulansky :Review Manager: Needed :Download: https://github.com/headmyshoulder/odeint-v2 :Description: odeint provides routines for numerically solving Ordinary Differential Equations, a task heavily required when approaching scientific problems numerically. In odeint we have implemented the most common algorithms in a modern, generic way which provides several advantages over existing implementations. The main focus of odeint is to separate algorithms from the underlying basic computation unit. This allows for example to easily use the power of modern GPUs via CUDA or OpenCL to speed up computational heavy simulations. Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

1 0

[interprocess] named_condition compile failure...
by Joseph Van Riper 13 Jul '12

13 Jul '12

I have either not understood the documentation, or found a bug in Boost.Interprocess's named_condition class. If I'm in error, I hope someone can help me. Otherwise, I will need to approach my needs another way. I assume that named_condition requires a named_mutex, as the documentation states in the Description here: http://www.boost.org/doc/libs/1_50_0/doc/html/boost/interprocess/named_cond… "This condition variable is designed to work with named_mutex<http://www.boost.org/doc/libs/1_50_0/doc/html/boost/interprocess/named_mute…> and can't be placed in shared memory or memory mapped files." Unfortunately, at least on a VC++ 2010 compiler, this doesn't seem to compile for me. I am using the following test code: #include "stdafx.h" #include <boost/interprocess/sync/named_condition.hpp> #include <boost/interprocess/sync/named_mutex.hpp> int _tmain(int argc, _TCHAR* argv[]) { boost::interprocess::named_mutex mutex( boost::interprocess::open_or_create, "test" ); boost::interprocess::named_condition condition( boost::interprocess::open_or_create, "test" ); condition.wait( mutex ); return 0; } With this code, I get the following error: 1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2248: 'boost::interprocess::interprocess_mutex::mutex' : cannot access private member declared in class 'boost::interprocess::interprocess_mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(117) : see declaration of 'boost::interprocess::interprocess_mutex::mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(67) : see declaration of 'boost::interprocess::interprocess_mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204) : while compiling class template member function 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::mutex_type *boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::mutex(void) const' 1> with 1> [ 1> Lock=boost::interprocess::named_mutex 1> ] 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(342) : see reference to class template instantiation 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>' being compiled 1> with 1> [ 1> Lock=boost::interprocess::named_mutex 1> ] 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\named_condition.hpp(156) : see reference to function template instantiation 'void boost::interprocess::ipcdetail::shm_named_condition::wait<L>(L &)' being compiled 1> with 1> [ 1> L=boost::interprocess::named_mutex 1> ] 1> c:\code\projects\testinterprocess\testinterprocess\testinterprocess.cpp(10) : see reference to function template instantiation 'void boost::interprocess::named_condition::wait<boost::interprocess::named_mutex>(L &)' being compiled 1> with 1> [ 1> L=boost::interprocess::named_mutex 1> ] 1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2064: term does not evaluate to a function taking 0 arguments - Trey

2 3

[1.50] Beta build of the PDF docs
by John Maddock 13 Jul '12

13 Jul '12

A PDF build of the 1.50(beta) docs is here: https://sourceforge.net/projects/boost/files/boost-docs/1.50/ Please let me know if there are any issues, John.

3 6

Macro fo rBOOST_NO_NUMERIC_LIMITS_MAX_DIGITS10 or use BOOST_NO_NUMERIC_LIMITS_LOWEST
by Paul A. Bristow 13 Jul '12

13 Jul '12

I have recently used BOOST_NO_NUMERIC_LIMITS_LOWEST to act as a proxy for support of numeric_limits<T>:: max_digits10 (as correctly suggested by John Maddock). Do we need yet another new macro for this, say BOOST_NO_NUMERIC_LIMITS_MAX_DIGITS10 or continue to use BOOST_NO_NUMERIC_LIMITS_LOWEST as a proxy. I think the latter will suffice (despite its unfortunate name for this task). But I think an addition to the configuration macro reference docs would be useful. Perhaps in macro_reference.qbk [[`BOOST_NO_NUMERIC_LIMITS_LOWEST`][Standard library][ Static function `numeric_limits<T>::lowest()` is not available for use. Also acts as a proxy for static const int `numeric_limits<T>:: max_digits10;` is not available for use. ]] I suspect there are also other additions that went with these two items, but I'm having a senior moment about what they are ;-( Views? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 12