September 2009 - Boost - lists.boost.org

Trac XMLRPC support
by Vladimir Prus 22 Mar '10

22 Mar '10

Would it be possible to have XMLRPC plugin installed in Boost Trac instance? See: http://trac-hacks.org/wiki/XmlRpcPlugin The installation appears to be fairly simple (and indeed seems to just work somewhere else). This will allow to use third-party tools to grab tickets from Boost Trac, which will hopefully lead to more issues fixed :-) - Volodya

4 5

boost::mpl::for_each and value_initialized
by Peter Foelsche 08 Feb '10

08 Feb '10

Dear All, what is the use of value_initialized in boost::mpl::for_each? It should be sufficient if the value is initialized by the constructor. value_initialized() calls memset() in before calling the constructor. This memset() is not being optimized away with gnu-c++ 4.4.1. What class does require zeroed memory to work correctly? Peter *** boost_1_40_0/boost/mpl/for_each.hpp Mon Aug 17 22:16:53 2009 --- boost_1_40_0.saved/boost/mpl/for_each.hpp Tue Sep 1 12:54:55 2009 *************** *** 71,78 **** // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. ! value_initialized<arg> x; ! aux::unwrap(f, 0)(boost::get(x)); typedef typename mpl::next<Iterator>::type iter; for_each_impl<boost::is_same<iter,LastIterator>::value> --- 71,78 ---- // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. ! //value_initialized<arg> x; ! aux::unwrap(f, 0)(arg()); typedef typename mpl::next<Iterator>::type iter; for_each_impl<boost::is_same<iter,LastIterator>::value>

5 10

Interest check: Boost.Mock
by Peter Bindels 26 Dec '09

26 Dec '09

Hi all, Over the past three-quarters of a year I've been working (with three friends) on a mocking framework for C++. In our vision, it would be a good complement to Boost.Test for testing classes separate from interfaces required - it would improve the ability to unit-test the classes that tie others together and that implement higher-level algorithms. It does this by creating an object that is "derived" from a given class at runtime, and replacing the functions with functions that redirect to verifying logic. The verifying logic uses basic structures to record expectations and to verify they happened. These ways of creating an object at runtime and modifying it are highly compiler dependant but remarkably portable - as it runs on at least 3 different compiler series (GCC, MSVC, EDG-based) and 5 platforms (Windows XP, Windows CE, Linux, QNX, bare platform), with few modifications. The library has been released under the name "Hippo Mocks" already. I'm interested in submitting it to Boost for three reasons. First of all, I believe that there may be obvious or very interesting optimizations or expansions I do not notice. Second, as Christian has elaborated on already, having the Boost tag on the project makes it more noticed and more used. As it has taken quite a bit of time from me already I would like people to use it. Third, Boost.Test allows testing code but does not support mocking. In the environment of unit testing, anything that is not a base library benefits from mocking by abstracting away details that are irrelevant and that will break your test unnecessarily. For Boost the main changes would be superficial in the naming and in using more default libraries instead of a new implementation. For Hippo Mocks I've decided to make no assumptions in anything over C++98 so there's a full Tuple implementation and so on. If there's an interest I'll spend the evening porting the code to qualify for the Boost coding norms and upload it to the vault (if I can - but that should be OK). I would like you to take a look at the code and tell me what you think of it. Thanks for your time. Kind regards, Peter Bindels

8 10

[TypeTraits] is it possible to add something to boost.type_traits?
by frederic.bron＠alcan.com 17 Dec '09

17 Dec '09

Dear boost implementers, TypeTraits is very useful, thanks you. However, recently, I needed something to know if a type is comparable (with operator<) and that was not in the library. Fortunately, somebody forwarded me an earlier post on the users list where I could find what I wanted. The implementation was inspired from boost/detail/is_incrementable.hpp I have written is_less_comparable, is_less_equal_comparable, is_greater_comparable... inspired from the same source and I wonder if it could be possible to add it to the library as I think it could be helpful for others. I give the source code below (if it is useful) but I am not able to make it fully general as it is in boost/type_traits. In particular, I do not understand all the macros that are used. Regards, F. Bron (See attached file: is_comparable.hpp) Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

11 23

Re: [boost] Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 02 Dec '09

02 Dec '09

I understand we'll never manage to please everyone. Apologies. For now I am settling on the boost::convert interface as I very much agree with the arguments Robert's put forward for it and I feel there is the least disagreement around this interface. Surely boost::convert() has issues of its own. However, I feel the path (convert::to_string->convert::to->convert) how I myself arrived to this logical (IMHO) conclusion seemed reasonable. More so, despite its subtle (to some) directionality the interface has proven to work (as it is essentially the same interface as for lexical_cast). You cannot deny that I made considerable sacrifices (my pets "string" namespace and "to/from" are gone, something I was ready to die :-) for yesterday...). I am hoping the others could make some concessions as well and we would settle on boost::convert()... for now. If some other issues pop up that we missed so far, we'll revisit the issue. It is because I would very much like to move forward and start looking at the functionality and implementation. Do you think it is possible or I am rushing things again? I somewhat cleaned up the implementation (removed to/from, etc.). However, before going forward I'd like to discuss one important thing that's been bugging me since Scott brought it up. Namely, all conversions are now implemented as discriminated functions like // string-to-type conversion template<class TypeOut, class StringIn> typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, detail::from_string<StringIn, TypeOut> >::type convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()) { return detail::from_string<StringIn, TypeOut>(from_str, default_value); } However, Scott mentioned that and I feel that might be cleaner if we could implement it as namespace boost { template<class TypeOut, class TypeIn, class Enable =void> class convert; } Then for every conversion we'll be able to encapsulate *complete* implementation in the respective specialization class. Like for string-to-type template< class TypeOut, class StringIn, typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, void>::type> class convert { convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()); }; The reason I like it is that it eliminates other support/intermediate classes (like something used-to-called boost::string::value<...> and detail::from_string) and we can do int i = convert(str, -1); // Nothing changed. a 'convert' instance created on the stack and converted to 'int'. convert<int, string> checked(str, -1); // named 'convert' is created. convert<int, string> checked = convert(str, -1); // the same but some might like this syntax better. if (checked.good()) success // we can check the success as ussed to with boost::string::value It feels that approach gives us considerably more room for expansion as some special conversions will be able to have methods only specific to that particular conversion. For this approach to work with algorithms we'll need class convert { static TypeOut apply(TypeIn const&); }; and then std::transform( ints.begin(), ints.end(), std::back_inserter(strings), convert<string, int>::apply); Thanks, Vladimir.

9 63

[thread] #2742 Why the at_thread_exit cleanup function is const?
by vicente.botet 25 Nov '09

25 Nov '09

Hi, Anthony, could you verify the patch and test I have attached to the ticket works for other platforms that cygwin? Thanks, _____________________ Vicente Juan Botet Escribá

2 1

[move][container] Review Request (new versions of Boost.Move and Boost.Container in sandbox and vault)
by Ion Gaztañaga 17 Nov '09

17 Nov '09

Hi to all, I've just uploaded to boost sandbox... http://svn.boost.org/svn/boost/sandbox/move/) and Boost.Vault... http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… ...new versions of libraries Boost.Move and Boost.Container. Online documentation can be found here: Boost.Move http://svn.boost.org/svn/boost/sandbox/move/libs/move/doc/html/index.html Boost.Container http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… I would like to request a review for both libraries. Boost.Move is quite small (just one header). Boost.Container depends on Boost.Move and Boost.Intrusive so you must download also the post-1.40 version of Intrusive placed in the same package (Boost.Container uses new features from Intrusive not included in Boost 1.40). Just take fresh Boost 1.39 folder and overwrite it with package contents. ************************ What's new in Boost.Move: ************************ ->The library has been modified to support moving rvalues of copyable AND movable types, a limitation of the previous version. This changes where proposed by Klaus Triendl in this thread: http://lists.boost.org/Archives/boost/2009/06/153266.php The library has now new macros to declare copyable and movable types and movable only types. Old macros are still there for backwards compatibility (specially unordered library which was also ported to this move sandbox) but I expect to remove them if current approach is considered better. ->Updated documentation and tests. ************************ What's new in Boost.Container: ************************ -> Added tests and documentation -> Updated the library to the new Boost.Move macros * * * I've tested both libraries in Windows XP using the following compilers: Visual 7.1, Visual 8.0, Visual 9.0, Intel 10.0, Mingw-gcc 4.3 and Mingw-gcc 4.3 in C++0x mode. The library should work on any C++03 conforming compiler Best, Ion

19 95

Boost.Variant is not EqualityComparable
by brook＠biology.nmsu.edu 12 Nov '09

12 Nov '09

I just ran into the case that Boost Variant does not satisfy the EqualityComparable concept. While it provides operator==() and operator<() (and therefore is LessThanComparable), it does not provide operator!=(), which is required for the EqualityComparable concept. Is this by design or oversight? It seems reasonable to expect that a Boost Variant model this concept, but perhaps I am missing something. In case it is by oversight, the following patch seems to provide the missing operator. Cheers, Brook --- boost/variant/variant.hpp.orig 2009-05-13 21:21:59.000000000 -0600 +++ boost/variant/variant.hpp 2009-05-25 19:21:40.000000000 -0600 @@ -1681,6 +1681,8 @@ return rhs.apply_visitor(visitor); } + bool operator!=(const variant& rhs) const { return !(*this == rhs); } + bool operator<(const variant& rhs) const { //

6 7

proposal interval container; ITL moved to the boost sandbox
by Joachim Faulhaber 11 Nov '09

11 Nov '09

Dear boosters, after completion of a lot of boostification work I moved my Interval Template Library to the boost sandbox in the boost project centric form: https://svn.boost.org/trac/boost/browser/sandbox/itl itl boost itl [itl_xt] [validate] libs itl [itl_xt] [validate] I have split up the original library into three parts: (1) itl, (2) itl_xt and (3) validate. Core part 1 'ITL' contains all interval container class templates. Only this part will be prepared for a formal submission. Part 2 'itl_xt' contains extended parts of the original library that do not belong to the core interval container data structures and might be proposed for later extensions. Part 3 'validate' contains the sources for the law based test automaton 'LaBatea' that has been used for an automated check of the ITLs correctness. Parts 2 and 3 do not yet conform boost standards and naming conventions and are not yet intended as contributions to boost. On the core ITL-part I have done the following: + Removed all virtual functions via introduction of mixins + Integrated deeper into boost libraries replacing own code by e.g. boost::type_traits and boost::mpl + Minimized the class template interfaces by transforming member functions into non member function templates. + Made interval containers more interoperable by overloading operators and global function templates. + Wrote a test suite using boost unit test tools. Tested for boost-instance types boost::date_time and boost::rational + Provided jamfiles to build and run examples and tests. + All examples and tests have been compiled, linked and run successfully with msvc_9.0 and gcc_3.4.4(cygwin). Next I am going to write boost style html-documentation. >From the boost web page I don't see a clear recommendation for a preferable way of doing that. Handcoded? Generated with BoostBook? Is there a reference library that has an exemplary standard documentation? Cheers Joachim

3 4

Time for another bug sprint (after 1.41 ships)?
by Marshall Clow 09 Nov '09

09 Nov '09

Earlier this year, we had a "bug sprint", where many people focused on fixing bugs in Boost. We managed to get the # of open tickets down from 800 to about 720. As of today, there are 820 open tickets in Trac. Is it time to focus on swotting bugs again? 1.41 is scheduled for release on 1-November; that's six weeks from yesterday. How about a bug sprint starting on 14-November, finishing on 22- November? That's two weekends - and finishes up before the American Thanksgiving holiday. -- Marshall P.S. This doesn't mean that people have to wait until November to fix bugs ;-) ;-)

12 25