February 2012 - Boost - lists.preview.boost.org

Update on maximum adjacency search implementation
by Fernando Vilas 21 Feb '12

21 Feb '12

Hi, I think I have finally fixed the maximum adjacency search... Since the last post: - All parameters other than the graph are available as named parameters - Visitor is now pass-by-value - Documentation written Still potential to-do: - Update documentation with graphical walkthrough on a small graph - Python interface? - Find a way to make the priority queue work without unwrap_ref() - Do not depend on one_bit_color_map internals in min_cut_mas_visitor - Other suggestions from Boost community -- Thanks, Fernando Vilas fvilas(a)iname.com

1 0

Discrete speedometer
by Justinas V. Daugmaudis 19 Feb '12

19 Feb '12

Currently Boost has date_time library and it especially has time_duration. However, what I find lacking is some means to track the number of discrete events that happen during some specified time_duration window. Something modelled after boost::progress. For example, consider that we are interested in how many files have been copied per five minutes, or how many packets have been received per ten minutes, etc. Obviously, the bigger the time window, the more stable the speedometer. I would like to do something like this: discrete_speedometer ds(posix_time::minutes(5)); // Tracks the events using the 5 minute window for( ... ) // Some inner loop { ds += number_of_events; } >From time to time I can do this: double events_per_second = speed_per_duration<double>(ds, posix_time::seconds(1)); or even more succinctly double events_per_second = speed_per_second(ds); I have implemented such a feature, and the code is here: http://people.binf.ku.dk/~jvd/discrete_speedometer.hpp Is there any interest in such a utility class? Regards, Justinas

3 3

[move] new rvalue reference emulation
by Jeffrey Lee Hellrung, Jr. 19 Feb '12

19 Feb '12

I've recently discovered (well, probably rediscovered) an alternate rvalue reference emulation, one which allows rvalues ***of any arbitrary (move-emulation-enabled) type*** to be captured in C++03 and identified as rvalues, rather than references-to-const (there is a drawback, though, which I'll get to below; as usual, there's no "free lunch"). This is in contrast to the current move emulation framework Ion has created in Boost.Move which, at best, allows you to capture rvalues of specific types. That is, if you can enumerate the types for which you want to enable rvalue capture, then you're good. For example, if you want to create a generic unary function some_fn, and you know you want to at least capture rvalues of type X, you could do: template< class T > void some_fn(T&); // captures (lvalue) references-to-non-const, explicitly created emulated rvalue references, *and* (lvalue) references-to-(X const) template< class T > typename boost::disable_if< boost::is_same<T,X> >::type void some_fn(T const &); // captures (lvalue) references-to-const *except* (lvalue) references-to-(X const) void some_fn(rv<X>&); // captures rvalues of X as emulated rvalue references However, if Y is any type other than X, the above overloads will capture an rvalue of Y as an (lvalue) reference-to-(Y const). This is one of the shortcomings of using the emulated rvalue reference rv<T>& as a function argument: it can't bind to rvalues in a context where the template parameter T is deduced. Now I don't know if the following proposition is a good idea or not, but I think it is worth considering. Again, we would like the emulated rvalue reference rv<T>& to bind to rvalues, but the problem is the deduction of the T template parameter. Instead of using rv<T>& to capture arbitrary rvalues, I'll use a kind of type-erased emulated rvalue reference, generic_rv<...> (for lack of a better name at the moment), which will just store a void pointer to the original, pre-type-erased object. Of course, we need some way to recover the object back from the void pointer, and that's what the "..." template parameters are for. This is where the (unfortunate) runtime overhead comes in, as some dispatching mechanism (e.g., function pointers) needs to be used to effect the recovery of the original, pre-type-erased object. The important difference between rv<T> and generic_rv<...> is that there's no T in the template parameter list "..." of generic_rv; more to the point, its template parameters are not deduced within the context of binding function arguments of some_fn, hence the compiler will be allowed to look for conversions from arbitrary rvalues to generic_rv<...>. Hopefully that gives enough of an introduction to the idea. Further details are probably best left to a code snippet. Comments? Specifically, should this be considered as an addition to Boost.Move's current emulation framework? Has anyone seen this technique before? ---------------- #include <iostream> #include <boost/type_traits/is_convertible.hpp> #include <boost/utility/enable_if.hpp> // rv<T>& emulates T&& template< class T > class rv : public T { rv(); rv(rv const &); rv& operator=(rv const &); }; template< class T > struct has_move_emulation : boost::is_convertible< T, rv<T>& > { }; // *** NEW EMULATED RVALUE REFERENCE *** // generic_rv< F, Result > also emulates an rvalue reference, but in a kind of // type-erased way. The actual object referred to is referenced by a void // pointer. To be able to cast the void pointer back to a pointer-to-object, we // need to package the void pointer together with some kind of dispatching // mechanism. We use a function pointer to an instantiation of cast_forward<T>. template< class F, class Result = void > struct generic_rv { typedef Result (*p_cast_forward_type)(F, void*); generic_rv(p_cast_forward_type p_cast_forward, void* p) : mp_cast_forward(p_cast_forward), m_p(p) { } Result cast_forward(F f) const { return (*mp_cast_forward)(f, m_p); } template< class T > static Result cast_forward(F f, void* const p) { return f(static_cast< rv<T>& >(*static_cast< T* >(p))); } private: p_cast_forward_type mp_cast_forward; void* m_p; }; // X is just a typical move-emulation-enabled class. struct X { X() { std::cout << "X::X()" << std::endl; } X(X const &) { std::cout << "X::X(X const &)" << std::endl; } X(rv<X>&) { std::cout << "X::X(rv<X>&)" << std::endl; } X& operator=(X) { std::cout << "X::operator=(X)" << std::endl; return *this; } X& operator=(rv<X>&) { std::cout << "X::operator=(rv<X>&)" << std::endl; return *this; } operator rv<X>&() { std::cout << "X::operator rv<X>&()" << std::endl; return *static_cast< rv<X>* >(this); } operator rv<X> const &() const { std::cout << "X::operator rv<X> const &() const" << std::endl; return *static_cast< rv<X> const * >(this); } // *** NEW CONVERSION OPERATOR *** // X provides an implicit conversion to generic_rv. template< class F, class Result > operator generic_rv< F, Result >() { std::cout << "X::operator generic_rv< F, Result >()" << std::endl; return generic_rv< F, Result >( &generic_rv< F, Result >::template cast_forward<X>, static_cast< void* >(this) ); } }; struct some_fn { template< class T > void operator()(T&) const { std::cout << "some_fn::operator()(T&) const" << std::endl; } template< class T > typename boost::disable_if< has_move_emulation<T> >::type operator()(T const &) const { std::cout << "some_fn::operator()(T const &) const" << std::endl; } // Notice that this overload requires template parameter deduction, hence // the compiler cannot apply an implicit conversion to rv<T>& from rvalues // of move-emulation-enabled types. In other words, this overload can only // bind to *explicitly* created emulated rvalue references, not to "real" // rvalues :( template< class T > void operator()(rv<T>&) const { std::cout << "some_fn::operator()(rv<T>&) const" << std::endl; } // *** NEW FUNCTION OVERLOAD TO CAPTURE RVALUES *** // Since this overload requires no template parameter deduction, the // compiler *can* apply an implicit conversion to generic_rv<...> from // rvalues of move-emulation-enabled types. Yes, there will be some runtime // overhead from the function pointer dispatching, but that will often be // preferable to copying x! void operator()(generic_rv< some_fn > const x) const { std::cout << "some_fn::operator()(generic_rv< some_fn >) const" << std::endl; return x.cast_forward(*this); } }; template< class T > T make() { return T(); } int main(int argc, char* argv[]) { int a = 0; int const b = 0; some_fn()(a); // some_fn::operator()(T&) const some_fn()(b); // some_fn::operator()(T const &) const some_fn()(make< int >()); // some_fn::operator()(T const &) const X x; // X::X() X const y; // X::X() some_fn()(x); // some_fn::operator()(T&) const some_fn()(y); // some_fn::operator()(T&) const some_fn()(make<X>()); // X::X() // X::operator generic_rv< F, Result >() // some_fn::operator()(generic_rv< some_fn >) const // some_fn::operator()(rv<T>&) const return 0; } ---------------- - Jeff

10 33

TR2 is dead; multiple TR's coming instead
by Beman Dawes 19 Feb '12

19 Feb '12

The C++ committee met last week. There was lot's of discussion and plans to markedly increase the size of the standard library. Boost has an important part to play; Bjarne Stroustrup hoped for "doubling the output of Boost." Herb Sutter is talking about an effort to shake libraries out of corporations and other large organizations. There seems be be a fresh infusion of energy, with quite a few new faces at the meeting. Plans have firmed and work begun on new C++ library work items. There are lots of changes in process, and these will affect Boost developers wishing to propose Boost libraries for technical reports or the standard itself. Here are some of the process changes: * Library proposals will be taken on as "work Items". A decision as to whether a work item ends up in a technical report, in the standard itself, or even becomes a stand-alone international standard, will be deferred until technical work is complete (I.E. full standardese complete, polished, and ready to ship). * Domain specific "Study Groups" will replace the LWG's current sub-groups. Study groups have official ISO standing, so can get more work done between meetings than the old sub-groups, which were unofficial. * Technical reports will likely be smaller than in the past, and may be domain specific. These changes are intended to allow work on different libraries to proceed in parallel. Medium to large libraries managed by study groups will most likely end up as a TRs and will ship when ready rather than being held waiting for a larger TR to become ready. The study groups set up so far: * SG1: Concurrency and Parallelism (chair: Hans Boehm). This is the old Concurrency sub-group. * SG2: Modules (chair: Doug Gregor). A new sub-group of the committee's evolution working group (EWG). * SG3: File System (chair: Beman Dawes). A LWG sub-group to handle the Boost.Filesystem work item approved at the meeting. * SG4: Networking (chair: Kyle Kloepper). A LWG sub-group to handle the Boost.Asio work item approved at the meeting. There should be a "Call for Library Proposals" in the committee's post-meeting mailing in roughly 10 days. --Beman

4 5

[regression-tests] run frequency
by lcaminiti 19 Feb '12

19 Feb '12

Hello all, Out of curiosity, I noticed that the trunk (and maybe also release) regression tests do not all run every day. http://www.boost.org/development/tests/trunk/developer/scope_exit.html Why is that? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-regression-tests-run-frequency-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

Can we use SVG (Scalable Vector graphics) for HTML Boost docs?
by Paul A. Bristow 19 Feb '12

19 Feb '12

In adding new functions and distributions to Boost.Math, I've become dissatisfied with diagrams and equations using PNG. They are either large and/or fuzzy :-( And they get fuzzier if you expand them :-(( All browsers now support native display of SVG (Scalable Vector graphics) quite well *except* older versions of Microsoft Internet Explorer (IE9 displays SVG OK). So we are still producing HTML versions of the Boost.Math docs using embedded PNG equations and diagrams. So everyone has to endure poor quality diagrams and equations, just so that a few MS IE<9 users can see the diagrams. 1 I'd like to have views on when we can disregard the Luddites and use SVG throughout? We'd also like to use MathML to display equations, saving authors a lot of effort and much reduced file sizes. All current versions of browsers *except Microsoft IE - even IE9* also support MathML. 2 I'd like views on using MathML - with the downside that all IE users would not see equations displayed? (Everyone can view the PDF version - which uses SVG, so displays nicely even when magnified). Thank you. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

3 3

[release, heap] bug fix merge request
by Tim Blechmann 18 Feb '12

18 Feb '12

i'd like to ask permission to merge one trivial fix for boost.heap from trunk into release [1]. it fixes an error that was reported on the boost-user list yesterday. i know it is pretty late, but as boost.heap is a new library it won't introduce a regression ... thanks, tim [1] https://github.com/ryppl/boost- svn/commit/65e619ffba40d3f2243cb235a906d4d75d9651c1

2 2

[graph] about subgraph
by Ernest Galbrun 18 Feb '12

18 Feb '12

Hello all, I would like to share my thoughts about the subgraph facility provided in the graph library. I have dived in it during the past few days because it looked nice, and it seemed to do what I was willing to do (that is, being able to work on various parts of the root graph while maintaining useful invariant). However, I have stumbled on surprising difficulties (I mean I would not have anticipated them from a boost component) : - The subgraph does not support serialization. In my opinion, it is a key feature for any kind of container. I found a broken version on the web and (as far as I can tell) fixed it, but it still seems to me that it is lacking from the original component. - The copy constructor is broken (see https://svn.boost.org/trac/boost/ticket/6564 but I see my comment on the second necessary patch was not sent, the bottom line is the original copy constructor led to errors when working on the copied graph). It is a central function, the fact that it has been broken without anyone but me noticing thus far leads me to think that a/ I am even less competent than I think I am in programming or b/ not many people use subgraph. - The remove_vertex is not implemented, and will not be (see https://svn.boost.org/trac/boost/ticket/4752 ). I was again very surprised when I discovered that, it was really an obvious function, the kind that justify for me the use of subgraph. And, reading further on the commentary for that "wont fix bug", the suggestion from jewillco of using a filtered_graph instead is perfectly relevant for my case. Nevertheless, I would rather have read such suggestion on the doc before chosing my component than at this quite late point. So I have one question and one suggestion to you boost (graph (subgraph)) developers : - Don't you think, given the lack of tests/users and the the missing features, that subgraph should leave the library ? - I think, if it stays, that the documentation should emphasize these points, and especially the last point : that filtered_graph is often a better solution. As a final note, I feel a little bit out of my place since I have absolutely no legitimacy criticizing the work of people who are by far more competent than me in computer sciences, so I won't feel offended if you point out that I am totally wrong. sincerey yours, -- Ernest Galbrun

1 0

unordered_map failing to compile on MSVC7.1 using STLport
by Robert Dailey 17 Feb '12

17 Feb '12

For some reason, I get the following compiler error on Visual Studio .NET 2003 when using STLport 5.2.1: boost\unordered\detail\allocator_helpers.hpp(318) : error C2039: 'select_on_container_copy_construction' : is not a member of 'stlpd_std::allocator<_Tp>' Any idea why this is happening? If not, what other information can I provide? --------- Robert Dailey

3 13

Move semantics for std::string?
by Robert Dailey 17 Feb '12

17 Feb '12

I'm using C++03 and would love some way to apply move semantics to a std::string. Can boost facilitate this in some way without using smart pointers? Consider an example like below (This is a contrived example, so assume NRVO does not apply): std::string GetInformation( int someNumber ) { // We use 'someNumber' to look up a string std::string myValue( "hello world" ); // Create the string here return myValue; } Above, the return value would result in a copy, I'd like to move it instead. --------- Robert Dailey

5 8