- Boost - lists.boost.org

Acknowledgement for Certs 4 Less
by Dave Abrahams 02 Sep '11

02 Sep '11

All--- For some time now, Boost has been using the CA-signed wildcard SSL certificate that was very generously donated by Certs 4 Less. I promised them, in return, that Boost would acknowledge them on our website, as we have done in the past for other donors. We acquired the certificate so we could accept e-payments for BoostCon, but in the end we decided to pay EventBrite to take payments for us... so as far as I know, the cert is only being used at the moment for https://svn.boost.org Two questions: 1. Where does the acknowledgement belong? 2. Can someone who knows how put it there? P.S. I would be very happy not to get separate answers to those, if someone who knows how to edit the website *and* an appropriate placement for the acknowledgement could just take care of it ;-) Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 6

Version 10 of Boost.Algorithm available
by Marshall Clow 02 Sep '11

02 Sep '11

Changes since -009 * Predicate versions of the search functions have been removed. * Search functions now work for raw pointers * Now use tr1/unordered_map everywhere - this should make (most versions) of gcc happy. * Now including <climits> in search.hpp, which defines CHAR_BIT. * Fixed a bug in boyer_moore::create_suffix_table, which caused the search to fail sometimes. * The skip table is now templated on the value_type being searched on, rather than the iterator type. * Documentation has been updated (more to come here) Thanks to Mikhail Levin, TONGARI, and Sebastian for bug reports. Since the vault is gone, I've put the code here: http://dl.dropbox.com/u/11048326/Boost.Algorithm-010.zip -- 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

2 1

[review] conversion - Kevlin's comments
by Gordon Woodhull 02 Sep '11

02 Sep '11

Hi Vicente, all - I got this comment from Kevlin Henney, author of lexical_cast: On Sep 1, 2011, at 11:45 AM, Kevlin Henney <kevlin(a)curbralan.com> wrote: > I was looking through the docs and they seem to offer a solution to a common family of conversion problems. 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. These are initial impressions only, so don't read too much into them. The eternal battle between power and simplicity. :-) Cheers, Gordon

2 2

[proto] Can't use functions in expressions?
by John Maddock 02 Sep '11

02 Sep '11

So.... I have a function that returns an expression template of proto::tag::function type, like so: template <class Exp>\ typename proto::result_of::make_expr<\ proto::tag::function\ , detail::BOOST_JOIN(func, _funct)<typename detail::backend_type<Exp>::type>\ , detail::big_number_exp<Exp>\ >::type const \ func(const detail::big_number_exp<Exp>& arg)\ {\ return proto::make_expr<proto::tag::function>(\ detail::BOOST_JOIN(func, _funct)<typename detail::backend_type<Exp>::type>() \ , arg \ );\ }\ and it all works fine, until I try and use the result of such a function call in an expression: sqrt(arg) + arg yeilds: 1>m:\data\boost\sandbox\big_number\libs\math\ide\extended_real\scrap\scrap.cpp(25): error C2893: Failed to specialize function template 'const boost::proto::detail::enable_binary<boost::proto::domainns_::deduce_domain,boost::proto::detail::not_a_grammar,boost::mpl::or_<boost::proto::is_extension<T>,boost::proto::is_extension<Right>>,boost::proto::tag::plus,const Left,const Right>::type boost::proto::exprns_::operator +(const Left &,const Right &)' 1> With the following template arguments: 1> 'boost::math::detail::big_number_exp<Expr>' 1> with 1> [ 1> Expr=boost::proto::exprns_::basic_expr<boost::proto::tag::function,boost::proto::argsns_::list2<boost::math::detail::big_number_exp<boost::proto::exprns_::basic_expr<boost::proto::tag::terminal,boost::proto::argsns_::term<boost::math::detail::sqrt_funct<boost::math::mpfr_real_backend<50>>>,0>>,boost::math::detail::big_number_exp<boost::proto::exprns_::expr<boost::proto::tag::terminal,boost::proto::argsns_::term<boost::math::big_number<boost::math::mpfr_real_backend<50>> *>,0>>>,2> 1> ] 1> 'boost::math::mpfr_real_50' So I figured I needed to update my grammar, so I tried adding this case: template<> struct big_number_grammar_cases::case_<proto::tag::function> : proto::function< proto::_ > {}; But still no joy (same error message). Any ideas on what I'm doing wrong? BTW I couldn't find any examples of using proto::function in a grammar, it wasn't obvious to me what it's template arguments should be, or indeed whether this actually enabled the function call operator rather than my use case? Thanks, John.

4 6

Basic boost::mpl::max_element question.
by Yves Dolce 02 Sep '11

02 Sep '11

Hi everyone, Once past the basic understanding of C++ metaprogramming (factorial, vector/typeslist, .), I must confess I have a hard time using max_element in my particular scenario. And I have not found a lot of samples on the net. Consider this "repro" first: template <unsigned char L> struct Level { static const unsigned char value = L; }; template <class LEVEL> struct CTA { typedef LEVEL Level_t; }; typedef boost::fusion::vector<CTA1, CTA2, CTA3, CTA4> CTAS; Now, using max_element, I'd like to pick the one CTAn for which CTn::Level_t::value is the biggest. Can you enlighten me? Thanks! An MPL/FUSION beginner. J

2 1

[TypeTraits] A patch for clang's intrinsics (was: [type_traits] is_enum on scoped enums doesn't works as expected)
by Michel MORIN 01 Sep '11

01 Sep '11

John Maddock wrote: >> Boost.TypeTraits does not use intrinsics for clang yet. >> (c.f. https://svn.boost.org/trac/boost/changeset/72725) >> >> >> this explains why it is not working now. Is someone working on this issue? > > Not me, we need a Clang expert to look into it - or at least someone with > access to Clang to take care of the testing - someone did submit a patch to > enable intrinsic support for Clang, but it broke more things than it fixed > so it got reverted :-( Let's proceed step by step. As a first step, I made a patch to use clang's intrinsics except problematic intrinsics (i.e. `is_pod` and `is_empty`). All the tests run successfully on gcc-4.4, 4.5, 4.6, clang (trunk) and Mac OS X Lion's clang (Apple clang version 2.1). Regards, Michel

4 7

Re: [boost] [any] new version
by Martin Bidlingmaier 01 Sep '11

01 Sep '11

> Mathias Gaunard wrote: >> You could make next_id a function with weak extern linkage, which should >> be able to make it work. Thanks for the replies, I hope I fixed the linkage problems now, by making next_id() inline. There were other linker related issues, which are hopefully fixed now as well. The modified any.hpp header and a simple linker test are attached -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

2 2

[shared_ptr] Implicit 2 phase construction with enable_shared_from_this
by Sebastian Karlsson 01 Sep '11

01 Sep '11

There's been some discussion about solving the problem with shared_from_this() not being available in the constructor. This is fairly natural as shared_ptr ownership doesn't happen until after the constructor leaves, and we're not even guaranteed that the object enters shared_ptr ownership at all. What I'm suggesting is the addition of a private void enable_shared_from_this<T>::accepted_shared_ptr() {}. Then inside enable_shared_from_this<T>::_internal_accept_owner we add: const_cast< T* >( static_cast< const T* >( this ) )->accepted_shared_ptr(); Just beneath: weak_this_ = shared_ptr<T>( *ppx, py ); This allows clients of enable_shared_from_this to add their own accepted_shared_ptr() which will correctly be called while I believe not breaking any old code. I just added the const_cast because I'm not familiar with the rationale behind _internal_accept_owner being const. This change nets us: 1 ) Generic code dealing with construction of shared_ptrs ( in any of its forms ) does not need to bother themselves with 2 phase construction. 2 ) The distinction between construction & transfer of ownership to shared_ptr makes it easier to cope with both the case where T is not managed by a shared_ptr and the case where it is. One gotcha I've found is that for example: struct foo : enable_shared_from_this< foo > { foo() { boost::shared_ptr< foo > tmp( this, null_deleter() ); } // We might be allocated on the stack, so use a null_deleter for now void accepted_shared_ptr() { /* here we can patch it up with shared_from_this(), which will use our assigned deletion strategy */ } } Does not behave as one would want to. Basically in this case I'd want to use a shared_ptr<> which makes no assumptions about whether we're managed by a shared_ptr or not, we want a shared_ptr which acts as a plain pointer. The problem however is that the shared_ptr which we construct with the null_deleter will grab the enable_shared_from_this before even construction is complete. This can be solved by the following, as seen in boost::make_shared: ... boost::shared_ptr< foo > empty_with_deleter( static_cast< foo* >( 0 ), null_deleter() ); boost::shared_ptr< foo > tmp( empty_with_deleter, this ); // This one is safe to use ... Which doesn't enter boost::detail::sp_enable_shared_from_this. Would love some input from someone a bit more knowledgeable about shared_ptr. Kind regards, Sebastian Karlsson

1 0

[review] Conversion - About specialization, overloading and ODR
by Vicente J. Botet Escriba 01 Sep '11

01 Sep '11

Hi, during the Boost.Conversion review and pre-review it has been argued that as the user must provide specializations of the conversion function for other UDT's, it could promotr ODR violations as two independent libraries can provide the same specialization making them incompatible for an end user. This issue is present for any library for which the user could provide an overload or could specialize a class. The standard library protects itself from this issue saying that is undefined behavior any specializations of standard classes (except maybe numeric_traits that has a single parameters and it is intendeed to be specialized by the library providing the UDT). My question is: Should Boost (all the Boost libraries) document explicitly that any class specialization or overload of free fuctions could result in undefined behavior? Is this already implicitly acknowledged? Best, Vicente

3 7

[review] Conversion review ends today
by Gordon Woodhull 01 Sep '11

01 Sep '11

Folks, The review of Vicente's Conversion library ends today. Unfortunately there have only been four reviews, which is hardly enough to provide proper feedback. If you've considered writing a review or if you have any thoughts about the topic, please speak up now. Or if you'd like to submit a late review, just let me know. Thanks, Gordon

5 19