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

[interprocess, 1.51] basic_managed_shared_memory::flush removed?
by Tim Blechmann 15 Aug '12

15 Aug '12

testing 1.51 beta, i figured out, that basic_managed_shared_memory::flush has been removed. this currently breaks compilation of some of my code. wouldn't it be cleaner to deprecate it for some time and maybe post a warning? also a comment in the release notes, how to port code to 1.51 would be very nice. thanks, tim

2 2

[date_time] warning removal
by Vicente J. Botet Escriba 15 Aug '12

15 Aug '12

Hi, Attached a patch to remove most of the warnings below. Could I commit it? There are 4 warnings I want to check ../../../boost/date_time/period_formatter.hpp:117:47: warning: unused parameter 'separator' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:118:47: warning: unused parameter 'start_delim' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:119:47: warning: unused parameter 'open_end_delim' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:120:47: warning: unused parameter 'closed_end_delim' [-Wunused-parameter] where void delimiter_strings(const string_type& separator, const string_type& start_delim, const string_type& open_end_delim, const string_type& closed_end_delim) { m_period_separator; m_period_start_delimeter; m_open_range_end_delimeter; m_closed_range_end_delimeter; } and private: range_display_options m_range_option; string_type m_period_separator; string_type m_period_start_delimeter; string_type m_open_range_end_delimeter; string_type m_closed_range_end_delimeter; }; Is an assignment missing or it was a typo while trying to avoid the warning? Best, Vicente ../../../boost/date_time/date.hpp:194:55: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date.hpp:195:67: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_duration.hpp:128:57: warning: extra ';' inside a struct [-pedantic] ../../../boost/date_time/date_duration.hpp:138:69: warning: extra ';' inside a struct [-pedantic] ../../../boost/date_time/date_duration.hpp:35:73: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_generators.hpp:37:30: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_generators.hpp:38:39: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_iterator.hpp:43:32: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_iterator.hpp:56:45: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_iterator.hpp:57:48: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_names_put.hpp:233:8: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/date_names_put.hpp:45:26: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/dst_transition_generators.hpp:21:38: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/local_time/custom_time_zone.hpp:46:7: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/local_time/custom_time_zone.hpp:47:40: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/local_time/local_date_time.hpp:211:31: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/local_time/posix_time_zone.hpp:118:39: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/period_formatter.hpp:117:47: warning: unused parameter 'separator' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:118:47: warning: unused parameter 'start_delim' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:119:47: warning: unused parameter 'open_end_delim' [-Wunused-parameter] ../../../boost/date_time/period_formatter.hpp:120:47: warning: unused parameter 'closed_end_delim' [-Wunused-parameter] ../../../boost/date_time/time_duration.hpp:254:57: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:22:77: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:33:45: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:34:48: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:35:64: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:36:65: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:37:66: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:38:65: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:39:64: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_iterator.hpp:40:65: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_zone_base.hpp:42:24: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/time_zone_base.hpp:43:33: warning: extra ';' inside a class [-pedantic] ../../../boost/date_time/wrapping_int.hpp:37:42: warning: extra ';' inside a class [-pedantic]

2 3

Trac ticket spam.
by Vicente J. Botet Escriba 15 Aug '12

15 Aug '12

Hi, could some one see what can be done with this spam https://svn.boost.org/trac/boost/ticket/7108? Best, Vicente

1 0

Announce: Boost 1.50 installer for 64-bit Windows now available
by John Wiegley 15 Aug '12

15 Aug '12

BoostPro is happy to announce that we now have a free 64-bit installer for Windows available for download: http://www.boostpro.com/download This version (which is only for 1.50 and onward) installs 64-bit libraries and/or DLLs for the following compilers: Visual C++ 8.0 (Visual Studio 2005 SP1) Visual C++ 9.0 (Visual Studio 2008 SP1) Visual C++ 10.0 (Visual Studio 2010 SP1) There will be no support for Visual C++ 7.1 for 64-bit, at any time. It continues to be supported for the 32-bit installer, however. Enjoy! -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

[asio] C++11 conformance problem: tie(this)
by Howard Hinnant 14 Aug '12

14 Aug '12

In three places asio/basic_socket_iostream.hpp does this: tie(this); In C++11 tie(this) has become undefined behavior, due to 27.5.5.3 [basic.ios.members]/p2: basic_ostream<charT,traits>* tie(basic_ostream<charT,traits>* tiestr); Requires: If tiestr is not null, tiestr must not be reachable by traversing the linked list of tied stream objects starting from tiestr->tie(). In libc++ it causes an infinite recursion as the ostream::sentry constructor calls flush on the tied buffer, and flush subsequently constructs a local ostream::sentry object (this is all C++11 required behavior). I could detect tie(this) in libc++ and ignore it (as a conforming extension). However I can not detect cyclic ties in general. My gut feeling is that a noisy error is better than ignoring it because whatever tie(this) is supposed to be accomplishing in asio, it isn't, at least not with C++11-conforming std::libs (ignore or crash seem to be std::lib's two obvious options). I believe the best course of action is to remove the three instances of tie(this) from asio. I do not know if this same issue occurs in other parts of boost. I scanned but didn't catch anything. Howard

1 0

[type_erasure][docs]uniform term for underlying
by Larry Evans 14 Aug '12

14 Aug '12

The doc: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… uses 3 terms: underlying actual contained to designate, essentially, the same thing, the actual type stored in the any. The docs would be clearer if a uniform term were used, with possibly a link to some glossary where the term was defined. -regards, Larry

1 0

[icl] HTML doc consumes more than 50 MB
by Michel Morin 14 Aug '12

14 Aug '12

The HTML doc in `libs/icl/doc/html/boost/icl` consumes more than 50 MB on my system. This directory contains about 2000 docs and there are many duplicate docs. Joachim, could you improve the situation? Thanks, Michel

3 4

C++11 decltype/SFINAE puzzler
by Eric Niebler 13 Aug '12

13 Aug '12

I'm running into a usability problem with the extended SFINAE rules that could effect best practice for all new C++ libraries. I'm hoping some clever person in the Boost community can help me. I find that in highly generic code, using decltype to define the return type of functions is very handy. Dave A. suggested a RETURNS macro to simplify this idiom: <https://groups.google.com/d/msg/boost-devel-archive/OzJ5Ft3pSnU/b_Ter9bgNqAJ> It's used like this: template<typename T> auto foo( T && t ) RETURNS( some-expression-using-t ); This is great and I use it a lot. Now, imagine you have a library of such functions calling other such functions: function A calls B calls ... calls Y, calls Z, all of which use decltype to declare their return types. Now, the user calls A passing a variable t for which the expression in Z's return type calculation makes no sense. Extended SFINAE kicks in, and Z simply disappears. Since Z has disappeared, the expression in Y's return type makes no sense, so Y disappears, too. And so on up the chain. The end result is that the user is presented with an error like: "no viable function A, template substitution failed." The user is given no information about which function in the chain failed to compile, or why. This is a serious usability problem! So, my question is: what can be done about this? Can we get the benefit of automatic type deduction in return types without causing SFINAE to drop functions from the overload set? Is there another trick we can use to report errors meaningfully when APIs are misused? The only solution I can think of is turn all the free functions in the chain into function objects and then using std::result_of to compute return types for them instead of using decltype directly. That means Dave's (very convenient!) RETURNS macro shouldn't be used, which is a bummer. (I think it also means that we need a noexcept_of template that computes the noexcept of an expression without causing the expression to appear in the function declaration, but that depends on how <http://llvm.org/bugs/show_bug.cgi?id=13286> gets resolved.) All suggestions welcome, -- Eric Niebler BoostPro Computing http://www.boostpro.com

9 19

[hash] test failure with current Intel compiler
by Beman Dawes 13 Aug '12

13 Aug '12

Release branch, using the current Intel compiler on Windows, a couple of filesystem tests are failing on my machine with the message: ..\..\..\boost/functional/hash/detail/container_fwd_0x.hpp(49): error: class template "std::tr1::shared_ptr" may not be redeclared in the current scope template <class> class shared_ptr; These tests are passing for GCC and VC++, but the Intel compiler uses the well regarded EDG front end. --Beman

2 1

[graph] interest in resumable dijkstra?
by Alex Hagen-Zanker 13 Aug '12

13 Aug '12

Dear boost-list, I placed the BGL algorithm of the dijkstra_shortest_path in a class, with the creation and initialization part separate from the main algorithm. This allows interrupting, resetting and resuming the algorithm. Would this be of interest to anybody? The following function call: dijkstra_shortest_path(graph, orig, parameter_pack); is separated into: auto dijkstra = make_dijkstra(graph, parameter_pack); dijkstra.init_from_origin(orig /*, optional_visitor*/); dijkstra.expand(/*optional_visitor*/); The make_dijkstra() function reads all parameters from the parameter_pack including color_map and priority_queue Visitors interrupt the calculation using a do_intterrupt() callback instead of throwing an exception. The function expand() can be called repeatedly, each time with another visitor. The implementation requires C++11, because of auto and lambda's, it also relies on the following patch: https://svn.boost.org/trac/boost/ticket/7130. To see for yourself: http://people.pwf.cam.ac.uk/ahh34/dijkstra_test.zip I am interested to hear your opinion. With kind regards, Alex

5 24

[type_erasure][doc]static_binding doc: no mention of PH to PH use.
by Larry Evans 13 Aug '12

13 Aug '12

The static_binding doc: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… contains: Description Represents a mapping from placeholders to the actual types that they bind to. However, the doc for: template < typename Concept2 , typename Tag2 , typename Map > any ( const any< Concept2, Tag2 > & other , const static_binding< Map > & binding ); here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure… contains: Requires: [snip] Map must be an MPL map with keys for all the placeholders used by Concept and values for the corresponding placeholders in Concept2. So the static_binding doc should contain something like: Represents a mapping from placeholders to the actual types that they bind to or a mapping from placeholders to placeholders, depending on where static_binding is used. HTH. -regards, Larry

1 0

[1.51.0] Beta 1 release candidates available
by Marshall Clow 12 Aug '12

12 Aug '12

Release candidate files for 1.51.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. The files (and associated md5s) are: 543e3498c4ce520bfa635607971be4fc boost_1_51_0_beta1_rc1.tar.gz 3f9beb290dad223c21822e9ef601fd80 boost_1_51_0_beta1_rc1.tar.bz2 0401b9c40aac37b7dd9ef7e33190270c boost_1_51_0_beta1_rc1.zip e5aa1cd82e71173197ee6794c2c035d2 boost_1_51_0_beta1_rc1.7z Thanks, --The release managers

10 15

[MPI] Jamfile tweak
by Daniel James 12 Aug '12

12 Aug '12

Hi, I've made a change to the MPI documentation Jamfile. The documentation build was failing on trunk because the same project name was used in 'libs/mpi/build/Jamfile.v2' and 'libs/mpi/doc/Jamfile.v2', so I gave the documentation project a more appropriate name: https://svn.boost.org/trac/boost/changeset/79974/ I'll merge to release once 1.51 is finished. Daniel

1 0

[1.51] Beta build of the PDF docs available
by John Maddock 12 Aug '12

12 Aug '12

A PDF build of the docs for 1.51 beta is now available from https://sourceforge.net/projects/boost/files/boost-docs/1.51.0/ John.

2 4

[fusion] 1.50.0 release broken on c++11
by Steve Lorimer 11 Aug '12

11 Aug '12

Hi folks I know it's been reported before, and has been fixed in trunk, but is there any plan to fix the released version? Reported here: http://boost.2283326.n4.nabble.com/fusion-g-4-6-deque-and-c-0x-compile-erro… Thanks Steve

4 4

[1.51] Context docs contains third party materials?
by John Maddock 11 Aug '12

11 Aug '12

Just noticed that the docs for the new context lib contains a "pdf" folder with a bunch of third-party PDF files, including the complete ISO C standard. Can we really re-distribute these? I would have thought not? Plus they occupy a few Mb of space when they could just be linked to elsewhere? Cheers, John.

2 2

[atomic] boost.atomic library/win32
by Tim Blechmann 10 Aug '12

10 Aug '12

hello helge, the shared library of boost.atomic on msvc is currently not really usable, as it does not export the pool_. atm, all boost.lockfree tests of msvc fail for this reason. also according to Zao on irc, it will need some specific treatment to avoid the compilation of a static library. tim [1] http://www.boost.org/development/tests/trunk/developer/lockfree.html

3 4

Cygwin svn client broken. Boost scripts failing as a result
by Beman Dawes 10 Aug '12

10 Aug '12

Failures in the inspection script have been tracked back to a cygwin problem. See http://stackoverflow.com/questions/11007024/cygwin-svn-e200030-sqlite-disk-… I did get a run of the trunk inspect script off this morning, but it may be erratic until this gets straightened out. If you are a cygwin svn user, and svn is working OK, you might want to avoid updating your cygwin installation until cygwin fixes this. --Beman

1 0

Meeting C++ - Full Program + Early Bird
by Jens Weller 10 Aug '12

10 Aug '12

Hi C++ & boost Community, just a short note to those who are interested in C++ conferences: The Schedule of Meeting C++ is online: http://meetingcpp.com/index.php/schedule.html The Keynote "Good C++11 Coding Style" is held by Michael Wong, the focus is on C++11 and boost. Early Bird Tickets are still available for one week until next wednesday! regards, Jens Weller

2 2

[intrusive_ptr] Why are comparison operators not friends?
by Carsten Fuchs 10 Aug '12

10 Aug '12

Hi all, I was just (re-)reading item 46, "Define non-member functions inside templates when type conversions are desired", in Scott Meyers "Effective C++, 3rd edition", and was wondering how and why the comparison operators for intrusive_ptr work when used with NULL, even though they're not friend functions as described in Scott Meyer's item 46. That is, the example program below compiles and links fine both with GCC 4.6 as well as with Visual C++ 2010 -- but how does do the compilers match the == operator, whose right operand is NULL, an int value? If I try to use the exact same templated binary operators like this in my own classes, and want NULL matched to one of the T* or U* operands, then I have to do it with friend functions or else the compilers don't find a match. Why does it work here? Best regards, Carsten #include <boost/intrusive_ptr.hpp> #include <iostream> class CRefCounted { public: CRefCounted() : RefCount(0) {} long RefCount; }; void intrusive_ptr_add_ref(CRefCounted* p) { ++(p->RefCount); } void intrusive_ptr_release(CRefCounted* p) { if (--(p->RefCount) == 0) delete p; } int main() { using namespace boost; intrusive_ptr<CRefCounted> p(new CRefCounted()); // I'd expect the next line of code to fail compilation, because the compiler // cannot find a match for operator == with left operand of type // intrusive_ptr<CRefCounted> and right operand of type int, but they do! if (p == NULL) std::cout << "p == NULL\n"; else std::cout << "p != NULL\n"; }

2 2

Re: [boost] Code question on fusion tag_of.hpp
by Dave Steffen 10 Aug '12

10 Aug '12

Mathias Gaunard wrote: > On 08/08/2012 23:39, Dave Steffen wrote: > > Hi Folks > > > > During a recent bug hunt, we came across the following (Boost 1.49, > > fusion/adapted/std_tuple/tag_of.hpp): > > > > #include <tuple> > > > > namespace std > > { > > template <typename... Elements> > > class tuple; > > } > > > > We find this rather puzzling -- why is this here? As far as we can > > tell, this doesn't do anything. > > It forward declares std::tuple so that it can specialize its traits > for it. > > But it really shouldn't do that, since there is no guarantee this > declaration is compatible with the standard one. Well, first of all, it's not a forward declaration, right? std::tuple is declared in whatever gets included with #include<tuple>, right? So it's not a forward declaration, it's a... what? A backwards declaration? :-) It's redundant at any rate. (Or I'm completely wrong, in which case I'm missing something.) And then, yes, this may or may not be compatible with the real std::tuple (which is what we were looking in to when we found this). -- Dave Steffen Software Engineer NUMERICA CORPORATION www.numerica.us (970) 461-2000 main (970) 612-2327 direct

3 3

boost 1.50.0 - function_input_iterator issue
by hans ewetz 09 Aug '12

09 Aug '12

In boost v1.50.0 the function_input_iterator constructor performs dereferencing which may prevent creation of an 'end' iterator. Should it not instead dereference in the dereference() function and possibly keep a dirty flag indicating if the current value is valid? Apologies if I have missed any similar posting related to this problem. Hans

2 1

[review] Multiprecision review results
by Jeffrey Lee Hellrung, Jr. 09 Aug '12

09 Aug '12

Summary -------- John Maddock and Christopher Kormanyos' Multiprecision library is ACCEPTED for inclusion into Boost, with 8 YES votes, 1 NO vote, and 1 CONDITIONAL vote. Details -------- Most reviewers noted that this was a sufficiently good first step toward extended precision arithmetic for inclusion into Boost. I think John and Chris will agree that there remains quite a bit of work left to do, but as one reviewer noted, John has an excellent track record regarding Boost development and Chris has been extremely dedicated during the pre-review development, review process, and post-review development, so I think this bodes well for the library's future. I'm going to highlight what I perceive to be some of the bigger issues raised by various individuals involved with in discussion, but I will share all my notes via Google Docs [1], and of course even further details are available in the mailing list archive. I note that many of the issues raised during the review have already been addressed by John and Chris. Mixed-Type Arithmetic -------- This has come up over and over again, especially in the context of allowing extended precision types within the same "family" to interoperate, which I think is tractable. Removing my review manager hat for a moment, perhaps a tag dispatching system similar to Boost.MPL or Boost.Fusion could be used, where all arithmetic types within the same family have the same tag, and hence only allow mixing types with the same tag. Most types will have a unique tag (which, I don't know, could default precisely to the arithmetic type?), but, e.g., Vicente's family of fixed-precision (and maybe even fixed-point) types would all be identifiable as being in the same family, and a traits class would determine the result types of the various arithmetic operations. Mixed-type arithmetic outside the above scope seems more tricky, but some users seem to still desire this in some form. Actual desired use cases will undoubtedly help here. Naming -------- Several commented on the redundancy of "mp_" prefix for identifiers already residing the boost::mp namespace. Narrowing Conversions -------- cpp_dec_float should round rather than truncate on narrowing conversions. Review manager hat off: I wonder if a radix-2 implementation of an arbitrary precision float should ultimately be prioritized and recommended over the present radix-10 implementation? It sounds like conversions in general should be reviewed, but I'm entirely sure myself where they all stand. If possible, narrowing conversions should be explicit while others (that would guarantee no loss of precision) may be implicit. This would be a departure from C++ builtin types. Performance -------- Phil, the lone NO vote, lamented that the scope of the library was evidently beyond simple fixed-precision (e.g., 128-bit or 256-bit) integral types, which is his desired use case. Indeed, at least in an earlier version of MP, expression templates seemed to give a performance penalty relative to using the raw back-end types; in theory, expression templates should give no performance hit, but compilers just may not be there yet. In any case, several reviewers requested that the scope of the library be clarified up front in the documentation. Regularization/Normalization of Back-End Behavior via Front-End -------- As Edward pointed out, different back-ends generally have different behavior on some "exceptional" cases, making use of the corresponding front-ends in generic contexts at times cumbersome (specifically when the generic context needs to handle said exceptional cases). A couple examples given were division-by-zero and conversion from a string with invalid characters. It is by no means *necessary* to regularize/normalize *all* such differences, but as many as possible and practical should be identified, considered, and documented. Separation of Data Structures and Algorithms -------- Though requested, John and Steven have maintained that this simply isn't very practical. I've gathered that there are too many special cases that (1) would make implementations a nightmare; and (2) would have be addressed very carefully (i.e., in a likely not-very-readable way) to avoid any performance hits. Since this has come up a few times, maybe something could be said in the documentation about this. Thanks to everyone who submitted reviews and participated in the discussion. Let me know if I left out anything you feel is particularly significant or inaccurate. - Jeff [1] https://docs.google.com/document/d/19YgtWBQt0lpjJoJDOtAlScZAZyOwzbHimiYTi-g…

7 6

Code question on fusion tag_of.hpp
by Dave Steffen 09 Aug '12

09 Aug '12

Hi Folks During a recent bug hunt, we came across the following (Boost 1.49, fusion/adapted/std_tuple/tag_of.hpp): #include <tuple> namespace std { template <typename... Elements> class tuple; } We find this rather puzzling -- why is this here? As far as we can tell, this doesn't do anything. (Well, it did participate in a long, ugly compiler error about variadic templates, which is why we found it.) What are we missing? Thanks for any insight. -- Dave Steffen Software Engineer NUMERICA CORPORATION www.numerica.us (970) 461-2000 main (970) 612-2327 direct

2 1

Re: [boost] [review] Multiprecision and uBlas
by John Maddock 09 Aug '12

09 Aug '12

>> Also running the tests for UBLAS with mp_number put in place of >> floats/doubles would be interesting. > > I've added modified versions of uBlas tests 1-7 to the multiprecision lib, > most of the tests pass, but there are two outstanding issues: > > * Test1: I had to disable a couple of tests because they trigger debug > assertons inside the STL. I get the same errors when testing with type > double, so I conclude it's a uBlas issue, not sure why they aren't > triggered in the regular regression tests though... > * Test3: I can't get this to compile, and the error are so inscrutable I > don't know what the issue is, I'd need some help from a uBlas expert to > figure those out. Hold on that was a mistake, test1 does pass, tests 3 and 7 don't compile for reasons I don't understand. I'd need some help from a uBlas expert to figure those out. John.

2 1