August 2012 - Boost - lists.boost.org

[build] Boost Build v2 documentation refer to "bjam"
by Klaim - Joël Lamotte 11 Oct '12

11 Oct '12

Hi, http://www.boost.org/boost-build2/doc/html/bbv2/overview/invocation.html I suppose this doc have not been updated in a long time? It still use "bjam" instead of "b2". Joel Lamotte

3 3

[config] explicit call of operator templates / msvc bug workaround
by Stefan Strasser 10 Oct '12

10 Oct '12

Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan

6 10

Who maintains boost MPI?
by Ralf Grosse-Kunstleve 04 Oct '12

04 Oct '12

Hi, we're looking for someone to merge a simple patch: https://svn.boost.org/trac/boost/ticket/6123 Ralf

4 4

Inspection tool run
by Paul A. Bristow 30 Sep '12

30 Sep '12

I've been trying to get Boost.Math off the Sinners List on the Inspection Report at http://boost.cowic.de/rc/inspect-trunk.html#math. It last ran 25 July 12, so I can't see if I have succeeded yet. When can I expect it to run again? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

8 12

[test] Trunk broken: What happened to test_exec_monitor?
by John Maddock 21 Sep '12

21 Sep '12

Testing on Trunk is apparently broken as the test_exec_monitor target has been removed from Boost.Test Trunk as of revision #74642. A quick grep shows 22 Jamfiles and over 200 targets dependent upon this. Whats happened? John.

14 68

[type_erasure] Difficulties with const
by Christophe Henry 19 Sep '12

19 Sep '12

Hi Steven, I have a const problem. Consider the following classes: struct Something { Something(const char* n): myName(n){} std::string const& getName()const { return myName; } std::string myName; }; struct Container { typedef std::vector< AnyNameable > PublicData; Container() { Something s1("bla"); Something s2("blabla"); myData.push_back(s1); myData.push_back(s2); } PublicData getData()const { PublicData res; for (Data::const_iterator it = myData.begin(); it != myData.end() ; ++it) { res.push_back(AnyNameable(*it)); } return res; } private: typedef std::vector< Something > Data; Data myData; }; Container is simply a class returning its "Something", hidden behind AnyNameable (nice way to realize C++ Coding Standards Item 42 BTW). I have a simple test function: void test() { Container c; Container::PublicData data = c.getData(); for (Container::PublicData::const_iterator it = data.begin(); it != data.end() ;++it) { AnyNameable a(*it); std::cout << "data: " << a.getName() << std::endl; // auxiliary question: why does this not work if I use const _self&? //std::cout << "data: " << (*it).getName() << std::endl; } } int main() { test(); return 0; } Now comes the interesting part. If I define AnyNameable using the concept interface, all goes (almost) well: template<class C, class T> struct getName { static T apply(C const& cont) { return cont.getName(); } }; namespace boost { namespace type_erasure { template<class C, class T, class Base> struct concept_interface< ::getName<C, T>, Base, C> : Base { T getName() { return call(::getName<C, T>(), *this); } }; } } typedef any< mpl::vector< getName<_self,std::string const&>, relaxed_match, copy_constructible<>, typeid_<> >, const _self& > AnyNameable; This compiles and outputs as expected. Problem 1: This will not compile std::cout << "data: " << (*it).getName() << std::endl; Hmmm ok not so bad. I'll gladly pay the extra line. (interestingly, it would compile and work without const) Problem 2: if I use the MEMBER macro: BOOST_TYPE_ERASURE_MEMBER((has_getName), getName, 0); typedef any< mpl::vector< has_getName<std::string const&()>, relaxed_match, copy_constructible<>, typeid_<> >, const _self& > AnyNameable; Then the code does not compile, unless I accept to give up all of my consts. On one hand, I will find it a easier job to sell type_erasure with the macro, OTOH, I will not give up my consts ;-) Would it be possible to have the macro AND const-correctness? Attached, a small test with the complete code. Thanks, Christophe

2 3

[contract] static_assert in contracts or not?
by Lorenzo Caminiti 18 Sep '12

18 Sep '12

Hello all, If static assertions make sense within contracts (preconditions, postconditions, and class invariants) is a questions that has been raised by both Vicente and Andrzej. I don't have a definitive answer so I'd like to discuss with the ML. On Wed, Aug 29, 2012 at 2:48 PM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > (6) > Static assertions: is there any value in providing them, given that we > already have this ability in Boost? I see that N1962 decided to abandon > them; I am pretty sure the reason was that static_assert was already there. > They somehow do not fit conceptually into the model of preconditions, > postconditions and invariants. Precondition, for instance tries to detect a > run-time condition occurring immediately before a function is called this > time. Static assertion is not even executed then. What point is there in > putting such assertion into the precondition? Documentation says " static > assertions can be selectively disabled depending on where they are > specified [...] so it is still important to logically associate them with > preconditions, postconditions, etc." -- technically this sentence makes > logical sense, but can you think of a single example where this selective > disabling of assertions would be useful? What is the point in disabling > such assertions at all, if they cost you nothing in run-time? I propose to > remove them and give a sort of recommendation that software quality is > assured by using a number of fairly independent tools: DbC, concepts, > static assertions. I think we can break down the question in two parts. Let's assume N1962 is accepted into C++1x so we have both contracts and static_assert. 1) Would you expect to be able to use static_assert within contract assertions (preconditions, postconditions, and class invariants)? Note that only boolean conditions are allowed by N1962 within contracts, general code is not allowed, therefore this is not a trivial question. For example, would you expect to be able to do the following option A: template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); to; // pointer not null from; // pointer not null } { // ... } In this case, would it ever make sense to use static_assert in postcondition and/or class invariants even if that were allowed? Or would you just use static_assert in the body, option B: template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ to; // pointer not null from; // pointer not null } { static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); // ... } I don't like this because the assertions are about the specifications (they assert a requirement of the interface) so they should go in the declaration and not in the implementation. Or maybe the assertions should be represented as concept requirements on To and From, option C: template< typename To, typename From > requires SizeofGreaterEqual<To, From>, Convertible<From, To> To* memcopy ( To* to, From* from ) precondition{ to; // pointer not null from; // pointer not null } { // ... } (Only we don't have concepts...) 2) Let's assume, we answered option A to question 1): template< typename To, typename From > To* memcopy ( To* to, From* from ) precondition{ static_assert(sizeof(To) >= sizeof(From), "destination too small"); static_assert(boost::is_convertible<From, To>::value, "incompatible types"); to; // pointer not null from; // pointer not null } { // ... } Would you expect these static_asserts to be disabled when precondition compilation and checking is turned off at compilation time? I'd think so. Thanks. --Lorenzo

4 11

[build] 1.49 unable to bootstrap boost
by yuri kilochek 12 Sep '12

12 Sep '12

Not sure if this goes here. On Windows 7, when I try to do bootstrap on a freshly unzipped boost 1.49 at the root directory, I get the following output: Building Boost.Build engine But that is as far as it gets before os terminates whatever it is doing with this (roughly translated from russian): **** STACK SIZE EXCEEDED **** **** WHILE PERFORMING RECURSION IN BATCH MODE **** Recursion depth=654, Stack usage=90 percent. **** BATCH PROCESSING ABORTED **** Is there a way to build boost bypassing this?

4 3

[Variant] C++11 variadic template implementation
by Florian Goujeon 11 Sep '12

11 Sep '12

Hi Boosters, I'd like to know if anybody were working on a C++11 version (using variadic templates) of Boost.Variant. I currently use the 'classic' version in my project, but since I need more-than-20-type variants, the compilation take a lot of time (extending the number of types that variant can support forces you to disable the use of precompiled headers). Plus, I'll need to use 70 type variants (MPL lists are physically limited to 50 types). If nobody has started to implement such a version yet, I'd be pleased to contribute. I've written an implementation. It's incomplete and far from perfect, but it could (hopefully) be a viable working basis.

6 16

[intrusive] patch to resolve compiler error for WinCE
by David Deakins 09 Sep '12

09 Sep '12

Hi Ion, I had a little bit of time to look into the compile error mentioned in ticket 6841 and determine a patch from detail/mpl.hpp that I think should resolve it. The patch is attached to that Trac ticket, although I could also just go ahead and apply it if you like. Thanks, -Dave

2 1