- Boost - lists.boost.org

[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