- Boost - lists.boost.org

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

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9

Re: [boost] [ICL] some improvement proposals
by Joachim Faulhaber 25 May '11

25 May '11

Hi Denis, thanks for your input again. You're a good analyzer of code. Maybe you want to consider writing a code review for libraries that are submitted for formal review on the boost developer's list from time to time :) 2011/5/19 Denis <denis(a)camfex.cz>: > Hi > > 1. (questionable because it changes the visible interface): rename > `left_open` and `right_open` to `right_closed` and `left_closed`. > > Reason: interval_bounds is used in bitwise operations with bit=1 means > `closed`. (1) I tried to consider common usage of naming of intervals that is known from math. There seems to tendency to assume closedness as default, while openness is indicated by naming: [x, y] an interval (also closed interval) [x, y) a right open interval (x, y] a left open interval (x, y) an open interval. (2) The bits are chosen so closedness is indicated by 1 and openness is indicated by 0 11 [x, y] an interval (also closed interval) 10 [x, y) a right open interval 01 (x, y] a left open interval 00 (x, y) an open interval. > `left_closed() | open()` resulting in `left_closed()` is more readable than > `right_open() | open()` resulting in `left_closed()`. > > Also, there are checkers `is_left_closed()` and `is_right_closed()` but not > for *_open ... again following common usage [see (1)]. > I had to use `class bounded_value` in my program (as in Icl details: > calculating lower and upper bound of interval separately, then constructing > the interval, bitwise or'ing bounds) > and I commented every usage of `right_open()` as `left closed` in order to > explain why I use `interval_bounds::right_open()` in constructing the left > `bounded_value` of the interval. > This resulted in the idea of renaming. > > Maybe making bit=1 mean `open` would be less painful for other users ? You see me inconsolable to hear that you are suffering pain from my library =( There is an concept "interval_bound" http://svn.boost.org/svn/boost/trunk/boost/icl/concept/interval_bounds.hpp that allows you to combine and-ing or-ing etc. of interval_bounds directly. I think that'll reduce your suffering, at least I hope so. Yes, it's missing from the docs. Would you create a ticket? BTW, you may locally extend the concepts in the way you desire and add functions according to you naming rational. > 2. define `contains(interval, elt)` as `!below(interval, elt) && > !above(interval, elt)` allowing the user to use `below()` and `above()`. > Sometimes it is useful. (3) Thanks for this suggestion. The design of the icl::interval's interface is done under the general requirement of minimality. The concept approach allows you always to add own function templates locally to the concept if you need them. > Anyway, all the versions of `contains()` are made of checking for both > bounds. If you found a suboptimal function implementation, please refer them specifically. I'd appreciate a suggestion for an optimization. You can also create a ticket. > 3. It would nice if the functions taking two intervals will have versions > taking an element as second argument. > I mean functions like `left_subtract`, `operator &`, etc. (I cannot tell all > the list at the moment) > Constructing temporary `close_interval` object in order only to pass it into > those functions is cheap with ints but would be expensive with > heap-allocated domains (blobs, strings, etc). This is worth considering. In my own use of intervals within the implementation of interval containers I never encountered the need for such functions ... yet they may be useful in other situations. What do others think? Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 2

[Iterator] Constness of transform_iterator's dereference operator
by Michel MORIN 24 May '11

24 May '11

(In the previous mail, "function call operator" should be "dereference operator". Sorry for this, I fix it and resend a mail.) A long-standing request that transform_iterator should use boost::result_of will be resolved in Boost 1.47. This is really nice news, but I have a concern related to this. In the new code, transform_iterator uses result_of<UnaryFunc(typename std::iterator_traits<Iterator>::reference)> to determine the return type of a functor. However, since transform_iterator's dereference operator is const, result_of<const UnaryFunc(typename std::iterator_traits<Iterator>::reference)> should be used instead. There is a patch for this fix in #5127: https://svn.boost.org/trac/boost/ticket/5127 Alternatively, to remove this inconsistency, we can strip the constness of transform_iterator's dereference operator by either A. Make UnaryFunc member data mutable as suggested in #4969: https://svn.boost.org/trac/boost/ticket/4969 or B. Add non-const overloads to - transform_iterator's dereference() function - iterator_core_access' dereference() function - iterator_facade's operator*() Patches for A (make_mutable.patch) and B (add_nonconst_overloads.patch) are attached in this mail. Comments? Regards, Michel

1 0

Re: [boost] [pre-review] Pimpl submission in the review queue
by Jeff Garland 24 May '11

24 May '11

Mostafa wrote: >> If you want to use the Code Collaborator site to examine the library, you must create an account. The good news is that there are other libraries there that you can review, too. If you wish to avoid creating an account, then you can follow the link on the review schedule to the code in the sandbox. > > Some may just want to follow a review without necessary participating in one. Requiring a user account discourages such activity, and in my opinion, creates an artificial barrier to further engagement between newcomers, or even existing Boost watchers, and Boost, even if it is a one-sided engagement. > > My thoughts, > > Mostafa This is all getting a bit ahead of my post-boostcon report on the library in a week review activities, but to answer this particular issue I'd say 1) you need a login to participate in the mailing list, 2) it's essential for spam prevention, and 3) data can be periodically put to the list to mitigate this issue. Below is a report (minor formatting tweaks) of the pimpl review generated from code collaborator. I think in all likelihood using one of the modern review tools is going to create a better environment overall. Jeff ************* Overview ID: 5 Status: Inspection Title: Pimpl idiom generalization. Creator: Vladimir Batov Created On: 2011-05-23 15:13 Finished On: 2011-05-24 11:55 Total Person Time: 01:27:06 Wall-Clock Time: 20:34:38 Total Reviewer Time: 00:46:00 LOC All Versions (Uploaded/Changed): 2997/0 LOC Final Versions (Uploaded/Changed): 2997/0 Document Pages (All): 0 Document Pages (Final): 0 Number of Defects: 16 Number of Comments: 8 ************* Overview: Support for value and pointer semantics. Support for boost::serialization. Support for separate -- interface and implementation -- class hierarchies (the Bridge pattern in GoF). Support for internal (implementation-only) run-time polymorphism (Non-Virtual Interface Idiom). Support for delegating constructors. Tutorial. Doxygen-generated docs. Linux and VS2008. ************* Participants Name Role Person-Hours Vladimir Batov Author 00:13:17 Robert Stewart Reviewer 00:46:00 Sean Chittenden Observer 00:06:13 ************* Defect Log ID Creator File Location Type Severity Text D22 Robert Stewart pimpl.hpp Line 25 Interface Major Names with two consecutive underscores are reserved for the implementation D23 Robert Stewart pimpl.hpp Line 25 Style Minor This macro name should start with "BOOST_PIMPL_" D24 Robert Stewart pimpl.hpp Line 54 Interface Minor pimpl<T>::xxxx_semantics is interesting, but xxxx_pimpl<T> is simpler and more direct. D25 Robert Stewart pimpl.hpp Line 157 Interface Major Names with double underscores are reserved for the implementation D26 Robert Stewart pimpl.hpp Line 158 Interface Major Names with double underscores are reserved for the implementation D27 Robert Stewart pimpl.hpp Line 159 Interface Major Names with double underscores are reserved for the implementation D28 Robert Stewart pimpl.hpp Line 160 Interface Major Names with double underscores are reserved for the implementation D29 Robert Stewart pimpl.hpp Line 244 Interface Major Names with double underscores are reserved for the implementation D30 Robert Stewart pimpl.hpp Line 49 Interface Minor What about Pimpl support for classes with a base class? Your design requires multiple inheritance. You could, instead, do the following: class Book : public value_pimpl<Book, Base> { }; template <class T, class Base = null_type> class value_pimpl : public Base { }; template <class T> class value_pimpl<T,null_type> { }; D31 Robert Stewart pimpl.hpp Line 291 Interface Minor This exposes too much of the implementation to the user. A construct() member function set, like the set of constructors your macro now generates, with perfect forwarding (and variadic support, when available), would be better. construct() can call the new operator and save the pointer, thereby hiding those details from the user. D32 Robert Stewart pimpl.hpp Line 57 Interface Minor This exposes the pseudo-smart pointer semantics. It shouldn't be public and it should probably be named "nil" rather than "null." The idea is that nil() returns an object with no implementation rather than a null pointer. D33 Robert Stewart pimpl-use-cases.html Line 346 Documentation Minor "It is not but not a 100% kosher" is nonsensical. Presumably, you mean something like, "This design has some problems." D35 Robert Stewart pimpl-use-cases.html Line 357 Documentation Minor s/nut shell/nutshell/ D36 Robert Stewart pimpl-use-cases.html Line 364 Documentation Minor s/More,/What's more,/ D37 Robert Stewart pimpl-use-cases.html Line 385 Documentation Minor s/for vast majority/for the vast majority/ D38 Robert Stewart pimpl-use-cases.html Line 386 Documentation Minor You can avoid the subsequent "he/she" awkwardness by rephrasing this sentence: "However, putting both book1 and book2 in a std::set results in two elements rather than one, despite the fact that they are supposed to represent the same Book." Overall Review Conversation Sean Chittenden I've been using Boost.Pimpl for almost a year now with great success (using it in conjunction with MSM, ASIO and Spirit). This has been an incredibly useful library for minimizing the interfaces exposed across components. There are three things that I'd like to see but are largely trivial: 1) a set of clean-room examples of the two implementations (i.e. split out the unit tests from a set of examples for pointer and value semantics), and an example of how to use Pimpl once it has been moved in to the boost namespace (I took a crack at this and was never successful at moving Pimpl in to the boost namespace).

1 0

Implicit cast rules
by Gregory Crosswhite 24 May '11

24 May '11

Hey everyone, Would someone please explain to me the implicit cast rule that prevents the following from compiling, and/or if there is a way around it? #include <boost/optional.hpp> #include <iostream> using namespace boost; using namespace std; struct C { operator optional<int>() { return none; } }; int main() { C c; cout << static_cast<optional<int> >(c) << endl; return 0; } Error message: In file included from /usr/include/boost/optional.hpp:15, from cast-to-optional.cpp:1: /usr/include/boost/optional/optional.hpp: In member function ‘void boost::optional_detail::optional_base<T>::construct(const Expr&, const void*) [with Expr = C, T = int]’: /usr/include/boost/optional/optional.hpp:262: instantiated from ‘boost::optional_detail::optional_base<T>::optional_base(const Expr&, const Expr*) [with Expr = C, T = int]’ /usr/include/boost/optional/optional.hpp:559: instantiated from ‘boost::optional<T>::optional(const Expr&) [with Expr = C, T = int]’ cast-to-optional.cpp:13: instantiated from here /usr/include/boost/optional/optional.hpp:392: error: cannot convert ‘const C’ to ‘int’ in initialization I can tell what is happening; it would seem that the implicit cast rule selects the optional() constructor before it even looks at my more specific cast operator. I'm just confused about why this should be, since I see no reason why constructor casts should be prioritized over operator casts. Is this just the way it is, a GCC quirk, something I'm doing wrong, etc? Thanks! Greg

5 4

Towards a plan to reduce active tickets
by Vicente BOTET 24 May '11

24 May '11

Hi, I've inspected the number of tickets since the las Bug Sprint and we ca see that we are having a mean of 18 additional active tickets each month. month created closed diff 01/05/10 99 107 8 01/06/10 122 316 194 // Bug Sprint 01/07/10 103 56 -47 01/08/10 115 120 5 01/09/10 85 34 -51 01/10/10 105 91 -14 01/11/10 109 80 -29 01/12/10 83 92 9 01/01/11 98 79 -19 01/02/11 98 71 -27 01/03/11 161 107 -54 01/04/11 105 145 40 MEAN 106,2 87,5 -18,7 * MEAN is calculated since the last Bug Sprint, that is for the last 10 months. I don't know what could be done to instead of having more active tickets each month having less. While the Bug Sprints are useful I think that we need to have a plan to reduce them is a regular way. I know that a lot of people would be at BoostCon. It would be great if this subject could be discussed in one of the general sessions. if you have any suggestion, please replay to this post and share your view with the Boost community. Best, Vicente

7 7

[Iterator] Constness of transform_iterator's function call operator
by Michel MORIN 24 May '11

24 May '11

A long-standing request that transform_iterator should use boost::result_of will be resolved in Boost 1.47. This is really nice news, but I have a concern related to this. In the new code, transform_iterator uses result_of<UnaryFunc(typename std::iterator_traits<Iterator>::reference)> to determine the return type of a functor. However, since transform_iterator's function call operator is const, result_of<const UnaryFunc(typename std::iterator_traits<Iterator>::reference)> should be used instead. There is a patch for this fix in #5127: https://svn.boost.org/trac/boost/ticket/5127 Alternatively, to remove this inconsistency, we can strip the constness of transform_iterator's function call operator by either A. Make UnaryFunc member data mutable as suggested in #4969: https://svn.boost.org/trac/boost/ticket/4969 or B. Add non-const overloads to - transform_iterator's dereference - iterator_core_access' dereference - iterator_facade's operator() Patches for A (make_mutable.patch) and B (add_nonconst_overloads.patch) are attached in this mail. Comments? Regards, Michel

1 0