February 2012 - Boost - lists.boost.org

Re: [boost] Is there interest in static code analysis?
by Ben Robinson 27 Feb '12

27 Feb '12

I would be interested in that static analysis tool. Thank you, Ben Robinson Sent from my Verizon Wireless smartphone Antony Polukhin <antoshkka(a)gmail.com> wrote: >Hi, > >I`ve recently found a tool and organization, that specializes on >static code analysis for C/C++. They already interact with some famous >open source projects and successfully find bugs. Looks like for >open-source projects they help for free. > >If someone is interested, I can send their web address in private >message (don`t want to ad on mailing list) > >Best regards, >Antony Polukhin > >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

vsix - template_profiler extension
by Brandon Kohn 27 Feb '12

27 Feb '12

Hello, I've put together a Visual Studio 2010 extension package which wraps the functionality of Steven Watanabe and Domagoj Saric's template_profiler to create a template profile tool. It also adds a command to profile the build time of a project or a single C++ file. Both functions are accessed from the context menu in the solution explorer tree-view. It's still fairly young and could use some kicking about. Are there any VC10 users here that would be interested in giving it a try? Cheers, Brandon

5 16

Is there interest in static code analysis?
by Antony Polukhin 27 Feb '12

27 Feb '12

Hi, I`ve recently found a tool and organization, that specializes on static code analysis for C/C++. They already interact with some famous open source projects and successfully find bugs. Looks like for open-source projects they help for free. If someone is interested, I can send their web address in private message (don`t want to ad on mailing list) Best regards, Antony Polukhin

1 0

[unicode] provide <boost/cuchar.hpp> header?
by Beman Dawes 27 Feb '12

27 Feb '12

The C++11 standard library provides a header <cuchar>, with a bit of Unicode support, based on C's <uchar.h>: Macros: __STDC_UTF_16__, __STDC_UTF_32__ Functions: mbrtoc16, c16rtomb, mbrtoc32, c32rtomb The functions provide conversion between char sequences and UTF-16/UTF-32. It would be useful to have a <boost/cuchar.hpp> header so that these functions could be used with existing compilers and standard libraries. Does anyone have an implementation of these functions they would be willing to contribute? --Beman

3 2

[mpl] ASSERT and other macros using unique IDs
by lcaminiti 26 Feb '12

26 Feb '12

Hello all, Currently BOOST_MPL_ASSERT_MSG cannot be expanded multiple times on the same line because (on GCC and alike) it uses __LINE__ to generate unique IDs. I have to program a macro that makes a bunch of static assertions when it expands so all these assertions made using BOOST_MPL_ASSERT_MSG are on the same line. I used BOOST_MPL_ASSERT_MSG_IMPL to pass the unique ID directly (which is generated by concatenating __LINE__ with the assertion counter which my macro keeps). However, this is not an ideal solution because BOOST_MPL_ASSERT_MSG_IMPL is part of a private API and it could change in the future. Is there any interest in making BOOST_MPL_ASSERT_IMPL part of the public API? (So I can directly pass the unique ID to use. I'd be best if the unique ID is not required to be numeric but just a concatenable token.) I had a similar issue with Boost.Concet's REQUIRES. #define CONTRACT_AUX_MPL_ASSERT_MSG_(counter, condition, message, types) \ /* unfortunately, need to use Boost.MPL implementation detail */ \ /* to pass unique ID (not just __LINE__) so this macro can be expanded */ \ /* multiple times on the same line if with different IDs */ \ BOOST_MPL_ASSERT_MSG_IMPL( \ BOOST_PP_CAT(BOOST_PP_CAT(message, _id_), counter), \ condition, message, types) // PUBLIC // // Allow to expand multiple assert macros on same line (without name clashes). #define CONTRACT_AUX_MPL_ASSERT_MSG(condition, message, types) \ CONTRACT_AUX_MPL_ASSERT_MSG_( \ BOOST_MPL_AUX_PP_COUNTER(), /* uses Boost.MPL impl detail */ \ condition, message, types) Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-mpl-ASSERT-and-other-macros-using-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[gsoc] project ideas
by Andrew Sutton 26 Feb '12

26 Feb '12

Just a reminder: if you have project ideas for Google Summer of Code, please submit them, either to me or post them here https://svn.boost.org/trac/boost/wiki/SoC2012 (under "Projects"). I think that this, any project ideas are fair game. I'm not terribly concerned with completely finishing something over the course of a single summer or having a goal of getting something into the main Boost release. I'd like to foster long-term participation in the Boost community, and I'd like to see more ambition in the kinds of problems we want students to tackle. Proposals for XML, some aspects of a UI library (whatever that entails), user input library (mice, raw-mode key input, touch, and physical sensors?), networking and protocol standards, etc. should be fair game. We can always set reasonable summer-long expectations for more ambitious projects. Obviously, short-term projects are fine -- I'm linking to Feature Requests as a source of project proposals -- but I hope that won't be the only kind of project proposed. If you have ideas, please post them earlier rather than later.. Thanks, Andrew

1 0

Inconsistency between std::minmax and boost::minmax
by Marshall Clow 25 Feb '12

25 Feb '12

So, C++11 has been approved, and in the new standard library, there is: template <typename T> std::pair<const T&, const T&> minmax ( const T& a, const T& b ) but in Boost, we've got: template <typename T> tuple< T const&, T const& > minmax(T const& a, T const& b) { I can easily change boost minmax to return a pair instead of a 2-element tuple, but that's an interface change, and might break existing code. On the other hand, giving them the same interface will make it easier for people to move to C++11's library functions. Any opinions? ideas? -- Marshall P.S. boost::minmax_element, on the other hand, already returns a pair, not a two-element tuple. I'm pretty sure it doesn't satisfy the C++ complexity requirements, but that's easily fixed.

3 3

Fix docs for boost.fusion
by niXman 25 Feb '12

25 Feb '12

Hello list. Diff is attached. -- Regards, niXman

2 5

Boost 1.49.0 release notice
by Beman Dawes 24 Feb '12

24 Feb '12

Release 1.49.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library (Heap) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_49_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.49.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

3 2

[1.49.0] Release candidate 2
by Beman Dawes 24 Feb '12

24 Feb '12

Another set of release candidate files is up at http://boost.cowic.de/rc/ Could someone please check that the doc files are now correct? Thanks, --Beman

4 4

[1.49] Release candidate PDF doc build available
by John Maddock 24 Feb '12

24 Feb '12

I've put a release candidate of the PDF documentation build for 1.49 here: https://sourceforge.net/projects/boost/files/boost-docs/1.49.0/ Let me know if there are any SNAFU's, Enjoy, John.

3 15

[integer] Bug in int_t<65>
by Vicente J. Botet Escriba 24 Feb '12

24 Feb '12

Hi, I was trying to instantiate a boost::int_t<65>::least and I didn't got an error. Unfortunately the size of the obtained type was 8. I think that there is an error in the meta-function class as there is a comparison without and with the sign bit in // ** template< int Bits > // bits (including sign) required struct int_t : public detail::exact_signed_base_helper<Bits> { typedef typename detail::int_least_helper < #ifdef BOOST_HAS_LONG_LONG (Bits-1 <= (int)(sizeof(boost::long_long_type) * CHAR_BIT)) + // ** #else 1 + #endif The same applies to uint_t. The fix of course consists in checking (Bits <= (int)(sizeof(boost::long_long_type) * CHAR_BIT)) + // ** Please could this be fixed in trunk? Best, Vicente

2 1

[spirit][qi] Fastest way to parse file
by Antony Polukhin 24 Feb '12

24 Feb '12

Hi, Boost.Spirit documentation advices to use multi_pass iterators for parsing files (or reading data to a STL container and then passing the begin and end of the container to Spirit.Qi). Much better solution would be to use a memory mapped file: boost::interprocess::file_mapping fm(filename.c_str(), boost::interprocess::read_only); boost::interprocess::mapped_region region(fm, boost::interprocess::read_only, 0, 0); const char* begin = reinterpret_cast<const char*>(region.get_address()); const char* const end = b + region.get_size(); Comparing to multi_pass iterator, mmap approach increased parsing speed more than 5 times, reduced memory usage and CPU load. Mmap approach is also a little bit faster than reading data to STL container and mmap sometimes requires less memory (depending on OS). I think, that such solution should be at least mentioned in Spirit documentation. May be mmap shall be wrapped in some class for tighter integration with Spirit and simpler usage: int main() { namespace spirit = boost::spirit; using spirit::ascii::space; using spirit::ascii::char_; using spirit::qi::double_; using spirit::qi::eol; spirit::file_parser first("multi_pass.txt"); // class that does mmap`ing std::vector<double> v; bool result = spirit::qi::phrase_parse(first , spirit::make_default_multi_pass(base_iterator_type()) , double_ >> *(',' >> double_) // recognize list of doubles , space | '#' >> *(char_ - eol) >> eol // comment skipper , v); // data read from file if (!result) { std::cout << "Failed parsing input file!" << std::endl; return -2; } std::cout << "Successfully parsed input file!" << std::endl; return 0; } Best regards, Antony Polukhin

3 4

Updated boost::base_from_member for C++2011
by Daryle Walker 22 Feb '12

22 Feb '12

This is in changeset 76982. I tried it on my system, with Apple-supplied GCC 4.0.1 and GCC-direct 4.6 (from MacPorts) on a Mac/PowerPC system. It just does the slam-dunk implementation of this concept that C++2011 allows (and therefore showing its power). The new code should be isolated to only systems that can handle it. Now the code is over the wall, and it's time to see who crashes & burns (hopefully no one) in the tests.... Daryle W.

4 15

Unsubscribe not working
by Ben Robinson 22 Feb '12

22 Feb '12

I have changed to a new email address for Boost and need to unsubscribe this one. The unsubscribe option here: http://lists.boost.org/mailman/options.cgi/boost-users is not working for me. Thanks in advance for your help. Ben Robinson

2 1

Boost BloomFilter Status
by Joel 22 Feb '12

22 Feb '12

Alej, How is progress going on your BloomFilter library? Back in August you were looking at being ready for proposal by EOY 2011. http://comments.gmane.org/gmane.comp.lib.boost.devel/222842 By any chance, have you looked at the NPS Bloom filter package? linked to from: http://afflib.org/ I'm very interested in your library and in your response to Phil's request for the ability to mmap in existing filters. Thanks! Joel

2 1

Re: [boost] TR2 is dead; multiple TR's coming instead
by Brian Wood 21 Feb '12

21 Feb '12

Beman Dawes : > 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." Sounds like Pharoah, but I'm sure he meant to be encouraging. > > 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. How will they be named? I'm fine with multiple TRs, but calling the next one TR2 seems reasonable to me. > > 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). I'm hoping there will be support for partial classes here. I don't think Vandevoorde's proposal takes this into account. Is there another modules proposal? > > * 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. > It looks like cryptography is slipping through the cracks. If there are signs of life in the crypto lib you're using please let me know. > There should be a "Call for Library Proposals" in the committee's > post-meeting mailing in roughly 10 days. While C++ needs more libraries, I'd like to see it get rid of/improve some existing libraries. Herb mentioned valarray being little used. I think that's right. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net "Prepare your work without, and make it fit for yourself in the field; and afterward build your house." Proverbs 24:27

6 7

[1.49.0] Release candidates available
by Beman Dawes 21 Feb '12

21 Feb '12

Release candidate files for 1.49.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

5 8

Review Calendar Update
by Ben Robinson 21 Feb '12

21 Feb '12

Hello, The GitHub repository for my submission of Singularity on the review calendar has moved. The new location is: https://github.com/cppmaven/Singularity Can this could be updated on the review calendar? Thank you kindly, Ben Robinson

2 1

Is there an equivalent to "bjam install-docs"?
by Steve M. Robbins 21 Feb '12

21 Feb '12

Hi, Is there a convenient way to install or copy the entire set of documents reachable from index.html? Since the docs are available on the web site [1], I suspect there might be, but I haven't found one. Thanks, -Steve P.S. I'm wondering about this because I need to copy the docs for the Debian package "libboost-doc". At the moment, I use a very inconvenient method that involves putting boost on a web server and using wget. [1] http://www.boost.org/doc/libs/1_48_0/

2 1

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