May 2011 - Boost - lists.boost.org

[pre-review] Pimpl submission in the review queue
by Vladimir Batov 26 May '11

26 May '11

I have a Pimpl generalization submission getting close to the top in the review queue. Rob Stewart suggested I'd post it to the new Boost Code Collaborator site for a pre-review. That's what I did with the following link to the pre-review (Review #5): http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=5 Your participation in that pre-review is most welcome. Best regards, Vladimir.

8 14

[phoenix] conflicts between result_of namespace and result_of class.
by Vicente Botet 26 May '11

26 May '11

Hi, I have found an error when we define new phoenix expression inside boost namespace. The following #include <boost/phoenix/core/limits.hpp> #include <boost/phoenix/core/call.hpp> #include <boost/phoenix/core/expression.hpp> #include <boost/phoenix/core/meta_grammar.hpp> #include <boost/phoenix/object/detail/target.hpp> #include <boost/proto/transform/lazy.hpp> #include <boost/phoenix/core/is_actor.hpp> BOOST_PHOENIX_DEFINE_EXPRESSION( // line 19 (boost)(convert_to) , (proto::terminal<boost::phoenix::detail::target<proto::_> >) (boost::phoenix::meta_grammar) ) results in darwin.compile.c++ ../../../bin.v2/libs/conversion_ext/test/builtins.test/darwin-4.2.1/debug/builtins.o builtins.cpp:19: error: ‘namespace boost::result_of { }’ redeclared as different kind of symbol ../../../boost/utility/result_of.hpp:35: error: previous declaration of ‘template<class F> struct boost::result_of’ builtins.cpp:19: error: ‘template<class F> struct boost::result_of’ used without template parameters builtins.cpp:19: error: expected unqualified-id before ‘<’ token It seems that the Phoenix result_of protocol and the utility result_of conflicts. Is this a real issue? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/phoenix-conflicts-between-result-of-name… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

Re: [boost] [ICL] some improvement proposals. Making selectors return const reference
by Joachim Faulhaber 26 May '11

26 May '11

Hi Denis, list, thanks for your interest in Boost.ICL and for your input. First a side note on the subject line: You did what is stated in the boost discussion policy http://www.boost.org/community/policy.html which says: Put the Library Name in the Subject Line [ICL] some improvement proposals. Actually as you can see on the list the convention that is actually established is [boost][Libraryname] bla bla for the developers list and [Boost-users][Libraryname] bla bla for the user's list. *Would someone update the web page accordingly?* Next I'd like to refer to a suggestion you've sent in off-list: 2011/5/16 Denis <denis(a)camfex.cz>: > Hi Joachim > > I also think that the functions upper() lower() first() last() have to > return const reference to domain_type instead of domain_type. > It is the same for int/double/time but has sense for my blobs. > Returning domain_type implies copying. > Same logic as std::vector's at(). This is interesting. With first() and last(), I don't think it is possible, because, dependent on the type of interval, we may generate a local temporary object via increment (++) or decrement (--), which can not be referred to. On the contrary for upper() and lower(), we should always be able to pass the constant reference of the member variables of the interval as return value. As you say, this avoids copying operations that might decrease efficiency, if domain_type objects are large. I think a modification to the code can be done without breaking existing code, at least I hope so. We could use typedef boost::call_traits<domain_type>::param domain_return_type as return type of lower() and upper(), so pass by value can be kept for built in types. Still I am kind of reluctant when I think of implementing this optimization: (1) Return by value works well and fast for the majority of applications where domain_type is built-in or small (2) Return by value allows for compiler optimizations that are taking care for copy elision in many cases. (3) It would be nicer if all selectors had the same signatures (simplicity). (4) Customization of intervals will become more obscure, less understandable by the new domain_return_type. (5) We'd increase expert-friendliness for a concern that is relatively local: Using ICL::intervals and interval_containers with large domain objects is unfavorable anyway. If efficiency is a mayor issue, we would have to consider not using the large objects directly in intervals but introducing a level of indirection. We may refer to them through (smart)pointers or iterators which are small and use an induced ordering for the interval containers for the Compare template parameter. x < y <=> (*x) < (*y) So I'm not shure what to do. Currently I tend to consider an implementation of the proposal. Thoughts? Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 2

Re: [boost] [Boost-commit] svn:boost r72166 - trunk/libs/thread/src/pthread
by Juergen Hunold 26 May '11

26 May '11

Hi Anthony, On Wednesday, 25. May 2011 23:19:01 anthony(a)justsoftwaresolutions.co.uk wrote: > Author: anthonyw > Date: 2011-05-25 17:18:59 EDT (Wed, 25 May 2011) > New Revision: 72166 > URL: http://svn.boost.org/trac/boost/changeset/72166 > > Log: > extern "C" functions are static > > Text files modified: > trunk/libs/thread/src/pthread/once.cpp | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > Modified: trunk/libs/thread/src/pthread/once.cpp > =========================================================================== > === --- trunk/libs/thread/src/pthread/once.cpp (original) > +++ trunk/libs/thread/src/pthread/once.cpp 2011-05-25 17:18:59 EDT > (Wed, 25 May 2011) @@ -22,12 +22,12 @@ > pthread_key_t epoch_tss_key; > pthread_once_t epoch_tss_key_flag=PTHREAD_ONCE_INIT; > > - extern "C" void delete_epoch_tss_data(void* data) > + extern "C" static void delete_epoch_tss_data(void* data) At least gcc-4.5.2 does not like this combination and bails out with: error: invalid use of 'static' in linkage specification gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) Please find a patch fixing this attached. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0

[review][autoindex] AutoIndex review result
by Daniel James 25 May '11

25 May '11

The AutoIndex reviews were unanimously in favour of inclusion so it has been accepted into Boost. Reviews were submitted by: Edward Diener, Paul A. Bristow, Barend Gehrels and Hartmut Kaiser. Artyom also took part. Some of the general issues that were raised: The name should be more consistent. There was a little confusion about installation, but this should be easier once it's part of boost. Since it works at the docbook level it can be a bit confusing for a pure quickbook user. We might need to add extra support to quickbook - possibly in the form of a template library. There was some confusion about the integration of the different documentation tools, e.g. the use of <quickbook-define> to optionally include content in quickbook, using 'xinclude' to include doxygen documentation in quickbook. I think this is more of a weakness of the quickbook documentation. A few reviewers wanted finer grained control over where index terms are inserted. It isn't clear how this could be done without adding too much complexity. Adding processing instructions to the xml is one possibility. The C++ header scanner picks up too many symbols for spirit (and will possibly do so for other libraries), some kind of annotation or configuration might help. Thanks to everyone who participated in the review, and to John Maddock for developing AutoIndex, Daniel James

2 1

Boost.Conversion: functors namming
by Vicente BOTET 25 May '11

25 May '11

Hi, during the Boost.Convert after review discussion there were some proposals to use Boost.Phoenix to build the functors. My question is what should be the name of the function that builds the functor. Some possibilities: short s=1; long l=3; using boost::phoenix::placeholders::_1; A- Use a different name: make_converter_to? s=boost::make_converter_to(*short*)(_1)(l) ; B- Use the same name in a different namespace. What about using "fp" as namespace (functional programming). s=boost::conversion::fp::convert_to(*short*)(_1)(l) ; C- Use the same name in the same namespace and use SFINAE/enable_if to select the correct implementation depending on the parameter. s=boost::convert_to(*short*)(_1)(l) ; Which are your preferences? Best, Vicente

5 12

[type traits] issue with operator traits and volatile qualifier
by Frédéric Bron 25 May '11

25 May '11

Sorry for being absent during the last month but it was very hard to find any time to work on the addition of the operator traits. I have not yet had the time to deal with the naming issue... But I found something more tricky while trying to solve the issue of reference types (& was just ignored). I never used the volatile qualifier but I found that the following behaviour breaks the code that detects if an operator returns void or not. Could someone tell me why the following code does not compile? bool f() { } void g(const volatile bool &) { } int main() { g(f()); return 0; } Many thanks, Frédéric

3 2

Re: [boost] [Lambda] Handling Bind/Lambda name clashes.
by Max Sobolev 25 May '11

25 May '11

On 25.05.2011 15:49, Eric Niebler wrote: > (fixing attribution...) > > On 5/23/2011 11:42 PM, Robert Jones wrote: >> On Thu, Apr 7, 2011 at 3:01 PM, Steven Watanabe wrote: >>> At some point in time, Eric Niebler wrote: >>>> And what is wrong with leaving bind in the boost namespace as I was >>>> suggesting and define boost::function like this: >>>> >>>> namespace boost { >>>> namespace function_adl_block { >>>> template<class Sig> >>>> struct function {...}; >>>> } >>>> using function_adl_block::function; >>>> } >>>> >>>> Now the "boost" namespace is no longer associated with >>>> boost::function, >>>> and boost::bind won't be found by ADL. > > It's probably a good general policy to move most/all types in Boost into > ADL-blocking namespaces like above, except those for which there is > reason to keep boost as an associated namespace. cool technique (for building more modular software / libs)!

1 0

[chrono, trunk] linux compile fix
by Tim Blechmann 25 May '11

25 May '11

today's trunk does not compile correctly. this trivial patch fixes the issue: thanks, tim Index: boost/chrono/detail/inlined/posix/thread_clock.hpp =================================================================== --- boost/chrono/detail/inlined/posix/thread_clock.hpp (revision 72154) +++ boost/chrono/detail/inlined/posix/thread_clock.hpp (working copy) @@ -21,6 +21,7 @@ thread_clock::time_point thread_clock::now( ) { + struct timespec ts; #if defined CLOCK_THREAD_CPUTIME_ID // get the timespec associated to the thread clock if ( ::clock_gettime( CLOCK_THREAD_CPUTIME_ID, &ts ) ) @@ -31,7 +32,6 @@ clockid_t clock_id; pthread_getcpuclockid(pth, &clock_id); // get the timespec associated to the thread clock - struct timespec ts; if ( ::clock_gettime( clock_id, &ts ) ) #endif { @@ -49,6 +49,7 @@ } thread_clock::time_point thread_clock::now( system::error_code & ec ) { + struct timespec ts; #if defined CLOCK_THREAD_CPUTIME_ID // get the timespec associated to the thread clock if ( ::clock_gettime( CLOCK_THREAD_CPUTIME_ID, &ts ) ) @@ -59,7 +60,6 @@ clockid_t clock_id; pthread_getcpuclockid(pth, &clock_id); // get the timespec associated to the thread clock - struct timespec ts; if ( ::clock_gettime( clock_id, &ts ) ) #endif {

2 1

Re: [boost] [pre-review] Pimpl submission in the review queue
by Sean Chittenden 25 May '11

25 May '11

> I have a Pimpl generalization submission getting close to the top in the review > queue. Rob Stewart suggested I'd post it to the new Boost Code Collaborator site > for a pre-review. That's what I did with the following link to the pre-review > (Review #5): > > http://demo.smartbear.com/boost/go?page=ReviewDisplay&reviewid=5 > > Your participation in that pre-review is most welcome. Fantastic! I signed up and am anxious to see this library accepte^Wreviewed^Waccepted. I've been using the Boost.Pimpl interface for nearly a year now and have been very successful and happy with its use in my projects. Second to ASIO, Boost.Pimpl has done more to impact the design, structure and maintenance of my projects than any other library (the benefits of a stable ABI are understated). Its use in maintaining clean interfaces and projects can't be understated. Historically I'd always saved implementing Pimpl for external facing bits and had always rolled my own interface, now I use it for everything internal or external because of how easy it is to thump out a Boost.Pimpl based interface. As I said on the review site, I've moved the Pimpl implementation in to "boost/pimpl" directory with success, though was not able to move the Pimpl library under the boost namespace. Actually... let me post a quick example that I wrote to both learn and quickly teach how to use Pimpl: https://github.com/sean-/Boost.Examples/tree/master/pimpl It takes about 60sec-3min for most people to have their "ah ha!" moment with that example (those unfamiliar with Pimpl would be wise to check it out, imnsho). I didn't dive in to the why, but in the implementation it is necessary open your namespace after you have defined your private implementation (see pimpl/pimpl_example_pointer_impl.cc:35). It would be nice to know why this is the case (or if it's a bug). Pre-review feedback: The examples used in the Pimpl unit tests are very very good, but it takes a few minutes to wade through the polymorphism and to tease out the most basic requirements for starting to use Pimpl. Walking through 1K of code to do something very simple is a bit daunting despite the obvious and nearly immediate dividends. Whenever I started using this, it was one of the best few hours I've ever spent learning something new. I'm very pleased to see this library move forward and look forward to its formal review. -sc -- Sean Chittenden sean(a)chittenden.org

4 3