July 2012 - Boost - lists.boost.org

[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