- Boost - lists.boost.org

[local] couple questions
by Jeffrey Lee Hellrung, Jr. 27 May '11

27 May '11

1) I notice from http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… that (proposed) Boost.Local has a dependency on Boost.ScopeExit. It seems that Boost.Local provides all the functionality of Boost.ScopeExit, and then some; at least, that's what seems to be implied by http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… It would seem reasonable then, maybe, should Boost.Local be accepted, to remove the dependence on Boost.ScopeExit and officially deprecate Boost.ScopeExit in favor of Boost.Local's BOOST_LOCAL_EXIT: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… What are your (you = Lorenzo or anyone else) thoughts regarding that development path? 2) I haven't read through the docs in *too* much detail yet, but I would guess from, for example, http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… that copying a Boost.Local functor amounts to something less than a deep copy, and possibly an entirely shallow copy. In other words, does int x = 0; void BOOST_LOCAL_FUNCTION_PARAMS( bind(int) x ) { // bind x by value, so a copy is taken... std::cout << ++x << std::endl; } BOOST_LOCAL_FUNCTION_NAME(f) boost::function< void ( ) > g(f); f(); g(); print "1" followed by "2" (my guess), or does it print "1" twice? I may have missed it entirely, but I'd like the semantics of copying a Boost.Local functor explicitly spelled out. P.S.: I noticed in http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… a misspelling in the comments of the last example, s/BOOST_IDENTITY_VALE/BOOST_IDENTITY_VALUE/. - Jeff

2 1

[type_at] Variadic template utility
by tymofey 27 May '11

27 May '11

While experimenting with varidic templates of the upcoming standard i discovered that quite often one would need to extract a type from parameter pack at specified position. While the task is trivial it would be quite handy to have a ready tool for this purpose, rather that specifying one yourself every time. You can find source code consisting of a single header at Vault/Utilities/type_at.hpp The usage is simple: boost::type_at<index, some_type_0, some_type_1, some_type_2, some_type_n>::type corresponds to some_type_index where index is in range [0..n]. For example: boost::type_at<2, int, float, char, long>::type corresponds to char. I hope this will be useful.

5 6

Test results down for a little while
by Daniel James 27 May '11

27 May '11

Hi, I just noticed that the server load was pretty high because someone was spidering the test results. So I removed them for a little while (I don't have time to work how to block an IP address). They'll be back soon-ish. Hopefully, whoever was doing so will understand. If you want an offline copy of the test results, you should probably ask on the testing list, I'm sure we can work something out. Daniel

1 0

[ICL] Compile error when using "is_numeric"
by sguazt 27 May '11

27 May '11

Hi, I've just checked-out the last SVN version of ICL and after compiling with gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) (flags: -Wall -Wextra -pedantic -ansi) I get these errors: --- [error] --- boost-trunk/boost/icl/concept/interval_bounds.hpp:89:58: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/concept/interval_bounds.hpp:89:58: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/concept/interval_bounds.hpp:104:58: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/concept/interval_bounds.hpp:104:58: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/left_open_interval.hpp:52:64: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/left_open_interval.hpp:52:64: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ ... boost-trunk/boost/icl/open_interval.hpp:51:64: error: type/value mismatch at argument 2 in template parameter list for ‘template<class Type, class Compare, bool Enable> struct boost::icl::numeric_minimum’ boost-trunk/boost/icl/open_interval.hpp:51:64: error: expected a type, got ‘boost::icl::is_numeric<Type>::value’ --- [/error] --- To solve this problem, it seems it is sufficient to prefix the use of "is_numeric" with "typename". Here below is the diff file: --- [diff] --- Index: boost/icl/left_open_interval.hpp =================================================================== --- boost/icl/left_open_interval.hpp (revision 72177) +++ boost/icl/left_open_interval.hpp (working copy) @@ -49,7 +49,7 @@ // Only for discrete types this ctor creates an interval containing // a single element only. BOOST_STATIC_ASSERT((icl::is_discrete<DomainT>::value)); - BOOST_ASSERT((numeric_minimum<DomainT, is_numeric<DomainT>::value >::is_less_than(val) )); + BOOST_ASSERT((numeric_minimum<DomainT, typename is_numeric<DomainT>::value >::is_less_than(val) )); } /** Interval from <tt>low</tt> to <tt>up</tt> with bounds <tt>bounds</tt> */ Index: boost/icl/concept/interval_bounds.hpp =================================================================== --- boost/icl/concept/interval_bounds.hpp (revision 72177) +++ boost/icl/concept/interval_bounds.hpp (working copy) @@ -86,7 +86,7 @@ { if(is_left_closed(decl) && !is_left_closed(repr)) { - BOOST_ASSERT((numeric_minimum<Type, is_numeric<Type>::value >::is_less_than(low) )); + BOOST_ASSERT((numeric_minimum<Type, typename is_numeric<Type>::value >::is_less_than(low) )); return icl::pred(low); } else if(!is_left_closed(decl) && is_left_closed(repr)) @@ -101,7 +101,7 @@ { if(!is_right_closed(decl) && is_right_closed(repr)) { - BOOST_ASSERT((numeric_minimum<Type, is_numeric<Type>::value >::is_less_than(up) )); + BOOST_ASSERT((numeric_minimum<Type, typename is_numeric<Type>::value >::is_less_than(up) )); return icl::pred(up); } else if(is_right_closed(decl) && !is_right_closed(repr)) Index: boost/icl/open_interval.hpp =================================================================== --- boost/icl/open_interval.hpp (revision 72177) +++ boost/icl/open_interval.hpp (working copy) @@ -48,7 +48,7 @@ // Only for discrete types this ctor creates an interval containing // a single element only. BOOST_STATIC_ASSERT((icl::is_discrete<DomainT>::value)); - BOOST_ASSERT((numeric_minimum<DomainT, is_numeric<DomainT>::value >::is_less_than(val) )); + BOOST_ASSERT((numeric_minimum<DomainT, typename is_numeric<DomainT>::value >::is_less_than(val) )); } /** Interval from <tt>low</tt> to <tt>up</tt> with bounds <tt>bounds</tt> */ --- [/diff] --- Can you fix it? Thank you very much!! Best, -- Marco

2 4

Re: [boost] Mixing different versions of Boost libs in a single process
by Grund, Holger 27 May '11

27 May '11

Well, BoostCon is over. So let me try again focusing on some specific bits: > > So the next best thing would be the ability to mix different versions > of Boost in a single process. Today, linkage names will be identical > across versions, which is problematic for static libraries on Windows, > and static libs and DSOs on Linux. [..] > Also there's BCP, which supports renaming namespaces. That's great, but > I guess it could be even better -- e.g. on toolchains where we have > inline namespaces or __attribute__((strong)). On Linux targets, symbol > versioning via GNU LD version scripts might make things a bit better -- > specifically, in that things gone wrong fail earlier and with better > diagnostics. > So when I run BCP on the entire boost tree I still get linkage names that would seem to clash across versions. Specifically, there's the graphml_reader namespace in libs/graph/src/graphml.cpp. Boost.Python and Boost.MPI have symbols that could cause problems, though these would seems to come from external OpenMPI and Python headers. I haven't really looked but it seems these should be fine so long as we build against the same OpenMPI and Python versions with the same configuration. What's the policy here? Do we want BCP to address these things? Or do we want libraries to not use namespaces outside of ::boost (or use linkage/symbol visibility to hide symbols from other DSOs)? Are there any tools to detect this kind of problem? I have a few things check two binaries for potential conflicts by walking debug info and symbol tables -- it's far from perfect and I can't just upload this to Boost, but I'd be happy to help out, if there's interest to get something into the regression tests. Thoughts, anyone? Thanks! -hg -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

2 2

[random] recent changes causing failures in accumulators tests
by Eric Niebler 27 May '11

27 May '11

Many accumulators tests are now failing on both trunk and release. I have tracked it down to recent changes in Boost.Random. I don't know for how long this has been happening. The accumulators tests use the lagged_fibonacci607 random number generator. The tests work by sending a large amount of random data through various statistical accumulators and checking that the results are within a certain tolerance of what they would be if the data were actually random. In Boost 1.45 and previous versions, this worked. (I haven't tested 1.46.) Trunk and release are hosed, leading me to suspect that this random number generator is no longer producing sufficiently random data. I have verified this by replacing boost/random on trunk with the one from 1.45. With this change, the accumulators tests pass. Steven, this seems like a regression. Can you look into this? -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[pimpl] Modularity thoughts
by Gregory Crosswhite 27 May '11

27 May '11

Hey everyone, As I have stated I think that it pimpl is acceptable enough as is even though it might contain "too much" for advanced users. Nonetheless, having reflected on some of the other reviews I do have some thoughts on some changes that could be made to it to make it more modular, while still preserving a default "all-in-one" option for ordinary users. Take the pimpl struct: =========================== template<class Interface> struct pimpl { struct implementation; template<class> class value_semantics_ptr; template<template<class> class> class pimpl_base; typedef pimpl_base<value_semantics_ptr> value_semantics; typedef pimpl_base<boost::shared_ptr> pointer_semantics; static Interface null(); }; =========================== and replace it with something roughly like =========================== template<template<class> class> equality_ops; template<template<class> class> ordering_ops; template<template<class> class> null_ops; template<template<class> class> bool_ops; template<class Interface> struct pimpl { struct implementation; template<class> class value_semantics_ptr; template<template<class> class> class pimpl_base; typedef pimpl_base<value_semantics_ptr> value_semantics_base; typedef pimpl_base<boost::shared_ptr> pointer_semantics_base; struct value_semantics: public equality_ops<value_semantics_base>, public ordering_ops<value_semantics_base>, public null_ops<value_semantics_base>, public bool_ops<value_semantics_base> {}; struct pointer_semantics: public equality_ops<pointer_semantics_base>, public ordering_ops<pointer_semantics_base>, public null_ops<pointer_semantics_base>, public bool_ops<pointer_semantics_base> {}; static Interface null(); }; =========================== Now take out all of the operations from pimpl_base and put them in separate subclasses like so: =========================== template<typename pimpl_base_type> struct equality_ops : public virtual pimpl_base { bool operator==(equality_ops const& that) const { return (impl_ == that.impl_); } bool operator!=(equality_ops const& that) const { return !(impl_ == that.impl_); } }; template<typename pimpl_base_type> struct ordering_ops : public virtual pimpl_base { bool operator<(ordering_ops const& that) const { return pimpl_base_type::impl_ < that.pimpl_base_type::impl_; } }; template<typename pimpl_base_type> struct bool_ops : public virtual pimpl_base { operator safebool_type() const { return safebool(pimpl_base_type::impl_.get()); } }; template<typename pimpl_base_type> struct null_ops : public virtual pimpl_base { typedef typename pimpl_base_type::interface T; static T null() { return pimpl<T>::null(); } }; =========================== Now the user can mix and match whatever operations he or she likes like, or simply take the full package by default. Note that I have intentionally left out constructors in the above classes because they aren't needed: since we are using virtual inheritance, the user of this library will be calling the constructor of pimpl_base directly, so we don't even have to worry about generating lots of boilerplate to forward the constructor arguments up to the base. In fact, this actually makes using this library simpler in one respect: normally a downside of using virtual inheritance in general is that every derived class needs to call the constructors of all bases, but in the particular case of this library this turns out to be a feature rather than a bug! The documentation discussed how when initializing a derived class you essentially have to call the constructor of the immediate base class and then undo it by resetting the pointer and then filling it with the correct type, but since we are using virtual inheritance now we no longer need this awkward procedure since we can just skip over the constructor of the immediate base class and call the constructor of pimpl_base directly! This also further removes the need for implementations to support a "null" value. Finally, and most importantly, a strong advantage of this design is that it is extensible so users and library writers can define their own operation that they would like to add to classes and mix them right in. Anyway, these are just some thoughts that I had. :-) Cheers, Greg

1 0

[pimpl] Preliminary Review
by Gregory Crosswhite 27 May '11

27 May '11

Hey everyone, Here are my preliminary thoughts regarding the pimpl library. First, I like the idea of having it or something similar to it be part of Boost because the functionality seems like it would be useful in a lot of cases. One of the strengths of including such a library in boost in my opinion is that it will appear in the "Libraries" list, which means that more people will be exposed to the idiom and will think of it as a possible option than they would otherwise. Put another way, Boost is both a collection of libraries and of best practices, so a good pimpl implementation belongs in boost even if it is a relatively small one. Now the question is whether this particular implementation itself is good enough. Honestly, I have trouble figuring out exactly what it does except by reading through the code since the documentation itself doesn't say what it does behind the scenes except to say vaguely that it implements "pointer semantics" or "value semantics". So one thing that the documentation really needs (among the many others that have been mentioned) is a section that clearly lists the features that it offers. One objection that Artyom reasonably raised is that this implementation may try to do too much, and doesn't offer much in the way of customization. However, people like Artyom are most likely going to be rolling their own implementation of the pimpl idiom anyway. I think that it is sufficient that a implementation be "good enough" for an ordinary user's needs that they won't have to think about any of the ugly details since it does all of that work for them, and to the extent that this is true of the current implementation Now for my thoughts on the code itself. Two of the classes in the implementation should probably be reviewed separately and put in different Boost libraries rather than the Pimpl library, namely safebool and value_semantics_ptr. safebool is an interesting solution to the problem that implicit conversions to the "bool" type implies implicit conversions to hosts of other types such as integers which can result in all sorts of unexpected behaviors that will bite you when you least expect it. safebool solves this problem by providing a convenient way for you to implement an effective "bool()" by instead implementing an operator that returns a special function-pointer that is specialized to your class and thus is equal neither in type nor value to a safebool for any other class; a minor cost that is presumably incurred by this is that a small amount of code will be added to the binary for this special no-op function, since I don't see how this can be optimized away. The implementation looks straightforward and the comments contain good documentation explaining both the usage and the rationale. I would recommend that safebool be accepted into boost and added to the utilities library on its own merits. value_semantics_ptr is a class that contains a pointer to data (or possibly a null pointer) and has the semantics that upon assignment it copies the data from another pointer, allocating (or freeing) its internal pointer if necessary. I think that this is a good idea and that something like this belongs in boost, but I suggest that the current implementation should be changed at least as follows before being accepted: First, it should be taken out of the pimpl<> class and made independent. Second, the traits struct member should be changed from a derived class to a second parameter in the list of template arguments to the value_semantics_ptr type, with the deep_copy member being pulled outside and being made the default value of the new second template argument. Alternatively, a type function --- e.g., copy_traits<T> --- could be used instead. Third, if Boost::Move is going to be ready soon it would be ideal if this class could be modified to support it in order to potentially save some extraneous copies. Fourth, one of the methods confuses me and apparently also the author: bool operator<(value_semantics_ptr const& that) const { return this->impl_ < that.impl_; // Should it be "*this->impl_ < *that.impl_" instead? } so this should be finalized. Fifth, the implementation will need to be fleshed out. operators such as * (dereference) and -> will need to be added, as well as some additional typedefs such as value, pointer, reference, etc. Operator safebool() will also need to be added. In conclusion, if pimpl is accepted I think it would be better for there to be a polished value_semantics_ptr that we feel comfortable having be directly tested and exposed to users be the back-end of this class than something hidden away, so when value_semantics_ptr is ready I think that it should ultimately be accepted to the Smart Ptr library. So much for safebool and value_semantics_ptr, now on to pimpl itself. The code looks straightforward and the comments document it reasonably well --- in fact, the ratio of comments to code in the main pimpl class is roughly 2:1, and in that count I was lazily including whitespace and single { and } lines as code lines, so that gives you a sense of how heavily it is commented. I have only taken a quick glance through it since this is a pre-review, but it all looks simple and straightforward to me, and it does a good job of generating tedious boilerplate so the user doesn't have to, exactly as it claims. On a side note, one additional set of semantics that I would recommend adding is move semantics, which could be implemented using the Boost::Move library. In conclusion, I think that this library should be broken into parts with safebool being put in utilities, value_semantics_ptr (and we can bikeshed over the name here of course :-) ) being put in smart ptr, and pimpl being put in a separate library. After this is done pimpl will be quite small, but I think that it pulls enough weight that it is nonetheless useful. To repeat what I said earlier, boost is not just a repository of libraries but of C++ best practices, so even if pimpl is small if it does a good job of capturing the pimpl idiom I still think that it should be accepted into Boost. Cheers, Greg

1 1

Library Review Tool (paging Jeff Garland) -- was : Re: [xint] Formal Review Result
by Michael Caisse 27 May '11

27 May '11

On 05/03/2011 09:12 AM, Matthew Chambers wrote: > On 5/3/2011 11:02 AM, Marsh Ray wrote: >> On 05/02/2011 03:04 PM, Barend Gehrels wrote (in another order): >>> >>> There was somebody who recently mentioned a scoreboard on this list >>> and I now think this is a good idea, because the review manager can >>> check if all reviews are taken into account. >> >> Yes, please. >> >> It would also make it more practical for an observer like me to sit >> down and simply read the reviews >> in an orderly way. >> >>> I understand that the traffic was really high, that review managers >>> do this voluntary, everybody don't have all the time, etc. >>> >>> Reviews are usually carefully written. People spend several hours on >>> it, sometimes days. Skipping these reviews is a sad thing. Writing a >>> library cost weeks, sometimes months or more. Forgetting reviews is >>> a very sad thing. >> >> Honestly, I would be more likely to help review libraries if I felt >> like it wouldn't be buried in >> the volume of the list. > > This where mailing lists fall to pieces. With proper forum software, > moderators could easily organize threads and change subject lines so > that it would be trivial to separate actual reviews from discussion. > And in fact, users would quickly adjust their behavior to fit the > paradigm. Instead, we have hundreds of messages with "review" in the > subject and only some of them are actual reviews, most being > discussion (like this one!). :( > > -Matt > _______________________________________________ Some time ago we all had a discussion like this and I believe Jeff Garland had mentioned Smart Bear's CodeCollaborator to aid in Boost Reviews. I used their product for a short time and was just taking a look at their web site again: <http://smartbear.com/products/development-tools/code-review/features/> I know there are other tools also (like Crucible) but CodeCollaborator also allows reviews of html docs which will obviously be handy. IIRC Jeff had mentioned that SmartBear might be willing to provide licensing for Boost (or opensource .. it is all fuzzy). I believe Jeff was in contact with them... but my memory might be failing (Jeff?? Are you there?) I would be willing to investigate this path further, including the administration and such of the tool, if it is of interest to the community. michael -- In the Sacramento/Folsom area? ** Profesional C++ Training mid-May ** http://www.objectmodelingdesigns.com/boostcon_deal.html Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

8 13

[network] Review Manager - Volunteer
by Michael Caisse 27 May '11

27 May '11

Review Wizards - Dean Michael Berris and I spoke today about his Network library submission that is in the review queue. I am willing to act as Review Manager for the library which is also acceptable to Dean. If there are no objections, please sign me up. Thank you - michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0