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

[trac] Type of ticket: "Bugs", "Patches", or "Feature Requests"?
by Niels Dekker - mail address until 2010-10-10 12 Feb '09

12 Feb '09

https://svn.boost.org/trac/boost/newticket has a Type dropdown-list that has "Bugs" as default. When my report has a patch file attached, should I set the Type to "Patches" instead? If fact, the report I have in mind is mainly a performance issue. I would like boost::array::swap to internally call boost::swap, instead of std::swap_ranges, mainly because some C++03 implementations of std::swap_ranges exchange the elements by doing element-wise copy operations, even when there is a custom swap for the element type. The new boost::swap utility takes care of calling the appropriate custom swap, whenever found by argument-dependent lookup (ADL). My report will have a patch. So is the type of such a report considered a "Feature Request", a "Bug", or a "Patch"? Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

2 2

Re: [boost] [log] Review-ready version in the Vault
by Vladimir.Batov＠wrsa.com.au 12 Feb '09

12 Feb '09

Andrey, Thank you for your contribution. I do not think I'll be participating in trial-runs or review as such. However, I read through the documentation and looked at the interface and I thought I'll give you my first (well, second, I looked at your lib. before) impression. I realize that everyone probably has something to say about logging and such a debate can get hot. So, I want to say beforehand that my reply is merely my impression (not a review or criticism of any kind). Firstly, it certainly seems very rich in features and configurable. That is certainly a huge plus for such a library as logging. However, I was truly overwhelmed by the documentation, the interface and the deployment examples. I seemed to be reading about familiar concepts -- severity levels, sinks, filters, formatters, streams/channels. However, after all that I did not feel an inch closer to actually deploying your library. I consider myself a moderately intelligent person but the seeming complexity felt quite intimidating. Somehow other implementations I read about (J.Torjo's, log4cpp, log4j, a bunch of loggers at SourceForge) went down much easier. Roughly, as a user I'd expect something as straightforward as boost::log log(name); // Create a log boost::log::sink sink = boost::log::sink(file)(stdout)(event_log); // Set up sinks boost::log::formatter fmt = boost::log::formatter(date)(thread_id)(name); // Set up the formatter boost::log channel = log.channel(channel-name); // Create a channel log(sink)(fmt); // Associate sinks and formatting if (log) log << "Hello, main world"; if (channel) channel << "Hello, channel world"; Maybe that's what your interface does. I just did not get that warm and fuzzy easiness/familiarity feeling after reading the docs and looking at the deployment examples. I feel there is a considerable room for improvement here. In particular I was left puzzled how you actually create a log instance (I think in the docs it is boost::src::logger). I'd expect to be able to create a log instance with a name and to be able to retrieve that same instance by the name anywhere in the program. That is, boost::log log1(name); boost::log log2(name); would be referring to the same log instance (pointer semantics). That'd be very liberating. Best, Vladimir.

8 18

Re: [boost] Profiling template instantiations (Steven Watanabe)
by PORKOLAB Zoltan 12 Feb '09

12 Feb '09

Hi Steven, We have created a framework for debugging/profiling template metaprograms in 2006. It might give you a few tips. It works based on the same idea you have. We instrument all template codes, both at the begining and at the end of each template we insert a special piece of code emitting warning messages of a well-defined form. Before instrumentation we create an XML file to remember the template positions in the source file. When we parse the warning, using this information we can reconstruct the instantiation stack knowing the original line numbers, identifiers, etc.. At the end we produce another XML for possible front-ends. The framework uses boost::spirit and boost::wave. We have also implemented and tested a visual studio plug-in. An overview of the whole idea: http://gsd.web.elte.hu/templight/ There is also a GPCE article about the framework, you can find it here: http://portal.acm.org/citation.cfm?id=1173746&coll=portal&dl=ACM&CFID=47731… or here: http://gsd.web.elte.hu/contents/articles/gpce06.pdf You can download both the VS binaries and the source from: http://people.inf.elte.hu/pocok Please feel free to use the code or any of the ideas. For technical question you can find Jozsef: jmihalicza(a)gmail.com or me. Regards, Zoltan

4 3

[TR1] Problems with TR1 include paths with Mingw?
by Richard Webb 12 Feb '09

12 Feb '09

Hi, I've got some code that i've been building with MSVC that uses the TR1 lib by adding the boost/tr1/tr1 dir to the include path, which i'm now trying to build using Mingw/msys. It seems to build ok using the code on the release branch, but using the current trunk i get: d:/Boost/BoostSVN/boost/tr1/detail/config_all.hpp:162:41: error: ../4.3.2/utility: No such file or directory Am i doing something silly, or have the recent changes to the include logic broken something for Mingw? For reference, i'm using the GCC 4.3.2 build from http://www.tdragon.net/recentgcc/ Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-TR1--Problems-with-TR1-include-paths-with-Mingw--tp2… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[any] implement reset for direct constructing (adapt to noncopyable)
by nowake＠fiercewinds.net 12 Feb '09

12 Feb '09

Hi All. I modified boost::any to adapt noncopyable object. The boost::any can use noncopyable object like this: _____________________________________________________________ struct B : boost::noncopyable { B() : v1(), v2() {}; B(unsigned int value1, unsigned int value2) : v1(value1) ,v2(value2) {}; unsigned int v1, v2; }; BOOST_AUTO_TEST_CASE(test02) { any test; //test = B(); // compile error //test.reset<B>(10, 20); // compile error test.reset<B, false>(10, 20); //any test2(test); // throw //any test2; //test2 = test; // throw BOOST_CHECK_EQUAL(any_cast<B&>(test).v1, 10); BOOST_CHECK_EQUAL(any_cast<B&>(test).v2, 20); } _____________________________________________________________________ If you are interested in this, please see #2748 for detail. https://svn.boost.org/trac/boost/ticket/2748 Thanks, Nowake

1 0

Boost 1.38.0 released
by Beman Dawes 12 Feb '09

12 Feb '09

Boost 1.38.0 has been released and is available from SourceForge. See http://sourceforge.net/projects/boost/ This release includes three new libraries: Flyweight, ScopeExit, and Swap. Updated Libraries: Accumulators, Any, Asio, Config, Date_Time, Exception, Filesystem, Graph, Hash, Interprocess, Intrusive, Lexical Cast, Math, Multi-index Containers, Proto, Regex, Thread, TR1, Type Traits, Unordered, and Xpressive. Other Changes: Experimental CMake build system. You can read the full release announcement here: http://www.boost.org/users/news/version_1_38_0 The release managers were Beman Dawes, Daniel James, Eric Niebler, and Rene Rivera. --Beman Dawes

7 9

Is it a bug in old version of boost?
by Bill David 12 Feb '09

12 Feb '09

I have the following code in my application. But I find it causes a serious memory leak with a product we are using. Our application is a plug-in to this product. But we are not sure what's the boost version included by this product. The following is the code (On Windows, the product should be written with Visual Studio 2003/2005): /** * @brief Convert modify time string to time_t for easy internal handling * @param str Modify time string returned by HTTP server, e.g. "Fri, 18 Jul 2008 11:53:14 GMT" * @return Corresponding time_t result */ time_t parseDate(const string& str) { ptime p; stringstream ss(str.c_str()); time_input_facet* timefacet = new time_input_facet("%a, %d %b %Y %H:%M:%S %z"); // will be automatically deleted by related locale object ss.imbue(locale(locale::classic(), timefacet)); ss >> p; tm t = to_tm(p); return mktime(&t); } And we find the problem is caused by time_input_facet* timefacet = new time_input_facet("%a, %d %b %Y %H:%M:%S %z"); ss.imbue(locale(locale::classic(), timefacet)); it seems related memory has not been released by locale or some memory is leaked by time_input_facet. We have tested above code separately with boost 1.35.0, 1.37.0, it's OK. So can anybody tell me if it's any problem in above code? Or is it a bug in old version of boost date_time or MS Visual Studio 2003/2005? Or how can I work around it?

1 0

[parameter] function types as named template parameters?
by Frank Mori Hess 11 Feb '09

11 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does Boost.Parameter support function types as named template type parameters? I'm trying to write a metafunction which lets you use Boost.Parameter to specify the template types for a boost::signals2::signal using named type parameters, as was suggested during the review. But it doesn't seem to work for the "Signature" function type. I get errors like: /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:264: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:270: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:352: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:359: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:365: error: function returning a function I can get it to work if I don't use Boost.Parameter for the "Signature" type, but only use it for the other 6 types. Also, I noticed BOOST_PARAMETER_MAX_ARITY defaults to 5, but signals2::signal has 7 parameters. I can't reliably redefine BOOST_PARAMETER_MAX_ARITY in my library header, since it must be defined before boost/parameter/config.hpp gets included. You can't redefine the arity and then re-include the parameter library headers like you can with Boost.Function. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJeO/v5vihyNWuA4URAtVIAJ9iHlncV/+QON81+qYYWzmzex3yDACg48Kc 2il7aidDE0Xj7tVUMmZaxLw= =eqjh -----END PGP SIGNATURE-----

2 6

Gauging interest in a thread-safe containers library
by Eric Greveson 11 Feb '09

11 Feb '09

Hi all, I've recently been doing some work that required thread-safe containers (queue, channel) and I found that in addition to these, a locking_ptr with similar semantics to boost::shared_ptr (except being thread-safe too) allowed me to perform all my threaded operations without needing to worry about synchronisation outside the container/locking_ptr code, and without a major impact on performance compared to coding locks in a slightly less generic (== paranoid) way. These have been re-used with some success by others, and a couple of containers (specifically the queue and channel) seem to be used commonly enough to be worthy of an inclusion in Boost.Thread or similar. This discussion has been had in the past, on this thread: http://lists.boost.org/Archives/boost/2004/09/71454.php Someone else mentioned it later, but there doesn't seem to be much else said here: http://lists.boost.org/Archives/boost/2005/11/96991.php I was wondering if there is more interest now, a few years on. Some of the pros I can think of are: * Writing correct thread-safe code can be tricky (I messed up the first time I wrote my queue). * Use of multithreading is perhaps more prevalent now, with many-core CPUs, than it was 4 years ago * Queues / channels in particular are very useful for building threaded pipelines etc, and more people might be tempted to use such programming techniques if a safe option was available "out-of-the-box" * A thread-safe shared pointer provides a lazy but effective way of synchronising data in many scenarios (my implementation supports the usual boost::shared_ptr stuff except for get(), -> and *: dereferencing is provided by calling an acquire() function which returns a scoped_lock object on which you can call * and ->.The destructor of the scoped_lock releases the lock.) * The thread-safe shared pointer means you could use a pop-copy queue without significant overhead (depending on use) * The code length for these class templates on a single platform is actually quite short (a hundred lines of code or so) Some cons: * Need to support all the platforms Boost works on * Not much interest for these containers last time * More code to maintain * Questions about how re-usable a synchronised queue is due to performance worries (I believe this not to be a major problem for a major class of problems - e.g. pipelining fairly long operations, such as in image and video processing) I'm sure I've missed some things, but I'd be interesting in hearing whether there's a positive or negative reaction to this. I'd be happy to contribute code for this - it wouldn't be the fastest possible code, but I believe that robust, lightweight, maintainable code is better than nothing in this case, even if it's not the very best lock-free implementation. Thanks for reading! Eric

6 10

[signals2] post-review rfc before moving to trunk
by Frank Mori Hess 11 Feb '09

11 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I've made some changes to Boost.Signals2 in response to some of the suggestions made during the review. Unless there is are show-stopper objections, I'd like to move Signals2 from the sandbox to the trunk in a week or two. For context, Stjepan Rajko's review summary is here: http://lists.boost.org/boost-announce/2008/11/0211.php The current Signals2 documentation is online here: http://www.comedi.org/projects/signals2/libs/signals2/doc/html/ Here is a summary of most of the changes made since the review: *Added a signals_vs_signals2_benchmark.cpp to the signals2/test subdirectory, and made some optimizations to signal invocation speed. *Made sure all macros were prefixed with BOOST_SIGNALS2_. *Added tests for boost::signals2::mutex and dummy_mutex. *Brought back boost::signals2::trackable class to ease porting of single-threaded code from Boost.Signals. *Deprecated deconstruct_ptr/postconstructible/predestructible in favor of deconstruct, a factory function similar to make_shared, which supports postconstructors and predestructors via ADL, similar to how the sp_accept_owner stuff works in boost smart_ptr trunk. *Expanded FAQ entry on differences between Signals and Signals2 by adding some notes on how to deal with the changes while porting. Changed the faq entry into a section. *Added documentation section on thread-safety which describes how the library uses its mutexes internally. *Added boost::signals2::signal_type metafunction which uses Boost.Parameter to allow named template type parameters for signals. *Added sections to the tutorial on postconstructors, extended slots, and signal_type. *Added examples section to docs, with compilable example programs extracted from tutorial, plus a few new ones. *Added a couple paragraphs to the design rationale section about optional_last_value and the signals2 mutex classes. *Added a small description to the optional_last_value reference page. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJkzY45vihyNWuA4URAivcAKCSGti3YkLGnzjmTr3EfAeN3FfiUwCg13S4 Jp54J65svUx6MVKNOsW31nU= =U39m -----END PGP SIGNATURE-----

1 0

[function] bug
by Okko Willeboordse 11 Feb '09

11 Feb '09

Applies for 1.37 and 1.38. Using VS2008, SDK 6.1 See ...\function\function_template.hpp 945 #if !defined(BOOST_NO_EXCEPTIONS) 946 try { 947 #endif 948 if (!f.empty()) { 949 this->vtable = f.vtable; 950 f.vtable->manager(f.functor, this->functor, 951 boost::detail::function::move_functor_tag); 952 f.vtable = 0; 953 #if !defined(BOOST_NO_EXCEPTIONS) 954 } else { 955 clear(); 956 } 957 } catch (...) { 958 vtable = 0; 959 throw; 960 } 961 #endif 962 } Line 953 #if !defined(BOOST_NO_EXCEPTIONS) must be moved 3 lines down like; 945 #if !defined(BOOST_NO_EXCEPTIONS) 946 try { 947 #endif 948 if (!f.empty()) { 949 this->vtable = f.vtable; 950 f.vtable->manager(f.functor, this->functor, 951 boost::detail::function::move_functor_tag); 952 f.vtable = 0; 953 } else { 954 clear(); 955 } 956 #if !defined(BOOST_NO_EXCEPTIONS) 957 } catch (...) { 958 vtable = 0; 959 throw; 960 } 961 #endif 962 }

3 4

[Date-Time] local date time "+=" Bug?
by Michael Mathews 11 Feb '09

11 Feb '09

Hi Folks, Here is the issue. If you have a local_date_time before the change in daylight saving time to Standard time or vice versa if you add one day to it the answer is incorrect. Here is a short example: #include "boost/date_time/local_time/local_time.hpp" #include "boost/date_time/posix_time/posix_time.hpp" #include "boost/date_time/local_time_adjustor.hpp" using namespace boost; using namespace local_time; using namespace gregorian; using namespace boost::posix_time; int main(){ typedef boost::date_time::local_adjustor<boost::posix_time::ptime, -6,boost::posix_time::us_dst> local_adj; std::string bryan_string = "CST-06:00:00CDT+01:00:00,M3.2.0/02:00:00,M11.1.0/02:00:00"; boost::local_time::time_zone_ptr tzptr(new boost::local_time::posix_time_zone(bryan_string)); boost::local_time::local_date_time fallback(local_adj::local_to_utc(ptime(date(2008,11,2), minutes(0))),tzptr); std::cout<<fallback<<std::endl; fallback+=days(1); std::cout<<fallback<<std::endl; fallback-=days(1); std::cout<<fallback<<std::endl; boost::local_time::local_date_time springahead(local_adj::local_to_utc(ptime(date(2008,3,9), minutes(0))),tzptr); std::cout<<std::endl; std::cout<<springahead<<std::endl; springahead+=days(1); std::cout<<springahead<<std::endl; springahead-=days(1); std::cout<<springahead<<std::endl; } this code produces the following output with 1.37 and 1.38 2008-Nov-02 00:00:00 CDT 2008-Nov-02 23:00:00 CST 2008-Nov-02 00:00:00 CDT 2008-Mar-09 00:00:00 CST 2008-Mar-10 01:00:00 CDT 2008-Mar-09 00:00:00 CST michael

1 0

Interest in a protected pointer
by Ray Logel 11 Feb '09

11 Feb '09

Is there any interest in pointer wrapper similar to scoped_ptr or shared_ptr which can be used for pointer member variable which can the referenced value can't be modified by non const functions? This class wouldn't be responsible for any memory management and could have a shared pointer version as well. For example: template<typename T> class protected_ptr { T * ptr; // ... T * get(); const T * get() const; // ... including operator* and operator-> } class Foo { protected_ptr<Bar> _bar; void Func1() { _bar->NonConstFunc(); _bar->ConstFunc(); } void Func2() const { _bar->NonConstFunc(); // Compile error _bar->ConstFunc(); // Ok } } Ray Logel

6 6

[1.39.0] Open for merging
by Beman Dawes 11 Feb '09

11 Feb '09

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but only with the permission of a release manager. In other words, except for new libraries, merging changes *does not* need permission from a release manager. I.e. just do it! The release schedule: * March 13, 2009: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * March 20, 2009: Release managers start QA checks. * April 3, 2009: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * April 10, 2009: branches/release closed for all library changes except when specific permission given by release manager(s). * April 17, 2009: Beta release target date. Further betas and/or release candidates as feedback dictates. * May 1, 2009: Release ship date. Links relating to this release: * Google Calendar with the release schedule: <http://www.boost.org/development/index.html>. * Release schedule explanation: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>. * Release practices for developers: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>. --Beman Dawes, Daniel James, Eric Niebler, Rene Rivera

1 0

Re: [boost] Boost 1.38.0 released
by Daniel James 11 Feb '09

11 Feb '09

2009/2/10 Marshall Clow <marshall(a)idio.com>: > Done. > And Boost 1.39.0 as a milestone for "to be fixed" We also need a few new components: https://svn.boost.org/trac/boost/ticket/2702 thanks, Daniel

3 2

[thread][repost] too many unnoticed posts
by vicente.botet 11 Feb '09

11 Feb '09

Hi Anthony, I have made a ticket of each one of the unnoticed post. #2742 Why the at_thread_exit cleanup function is const? Bugs Problem #2741 proposal to manage portable and non portablethread attributes Feature Requests Not Applicable #2740 thread_group::size complexity Feature Requests Optimization #2739 shouldn't at_thread_exit work on the main thread? Bugs Showstopper #2738 at_thread_exit move overloading Feature Requests Optimization #2664 Add unique_lock constructor taking a Duration Feature Requests Problem I can understand that you are very busy. Let me know if I can help you with these tickets. Best, Vicente

2 2

Trac system Milestone
by vicente.botet 11 Feb '09

11 Feb '09

Hi, I see in the Trac system that there are bugs with Milestone 1.36, 1.37. 1.38 and To be determined. As we will not have 1.36.x, 1.37.x releases, and possibly neither 1.38, shouldn't we change the Milestone to 1.39? For the To be determined, shouldn't we change to the corresponding Milestone Boost 1.39, Boost.Jam 3.1.18 Boost.Jam 4.0.0, Website 1.X. Maybe the ToBeDetermined Milestone is not a good idea. I have not counted the tickets without a Milestone, I don't know how to do. BTW, Should'nt the version be a mandatory field? As there are 196 + 97 + 156 + 181= 630 tickets to change it would be great if there is an easy way to do that. Best, Vicente Milestone: Boost 1.36.0 Completed 6 months ago (08/15/08) 62% Closed tickets: 324 Active tickets: 196 / Total tickets: 520 Milestone: Boost 1.37.0 Completed 3 months ago (11/02/08) 55% Closed tickets: 120 Active tickets: 97 / Total tickets: 217 Milestone: Boost 1.38.0 Completed 7 hours ago (02/10/09) 38% Closed tickets: 96 Active tickets: 156 / Total tickets: 252 Milestone: To Be Determined 61% Closed tickets: 279 Active tickets: 181 / Total tickets: 460

1 0

Futures Review Starts Today - January 5, 2009
by Tom Brinkman 11 Feb '09

11 Feb '09

Futures Review Starts Today - January 5, 2009 Braddock Gaskill http://braddock.com/~braddock/future Anthony Williams http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp Please review one or both libraries for submission to boost. Apparently, Anthony Williams' submission has also been sumbitted the C++ standards committee. Status unknown. As always, here are some questions you might want to answer in your review(s): What is your evaluation of the design(s)? What is your evaluation of the implementation(s)? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library(s)? Did you try to use the library? With what compiler(s)? Did you have any problems? How much effort did you put into your evaluation(s)? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? Do you think the libraries should be accepted into Boost as-is or should they be merged? Apparently, there has been various discussions about these two libraries last six months. The authors will need to bring us up to date as to why they want their libraries to be reviewed seperately. Also, each author should evaluate each others library and point out the differences in their implentations. These will serve as useful discussion points. The ideal outcome in my mind would be a resubmitted submission, incorporating the best ideas from each. Tell me if you share this view or what is your preferred result. As always, your reviews will certainly assist the authors in improving their libraries even further. Thank you in advance. Please feel free to participate in any discussion even if your not going to provide a full review. Review Manager Tom Brinkman

13 61

[test] como failures
by Steven Watanabe 11 Feb '09

11 Feb '09

AMDG See for instance http://tinyurl.com/anwyuk Simply switching from setenv to putenv in boost/test/utils/runtime/putenv.hpp seems to solve the problem. Since libcomo just inherits putenv from the C library, I don't understand what this workaround is supposed to be doing. In Christ, Steven Watanabe

2 1

Detecting reuslt_of support - Error with VC 9
by Joel Falcou 11 Feb '09

11 Feb '09

I've developepd this code snippet to detect if a type has the proper inner types for supporting result_of protocol : http://codepad.org/mcY4K7Sf It works fine under gcc and icc but fail under VC 9 with the following error : error C2903: 'result' : symbol is neither a class template nor a function template error C3202: 'result' : invalid default argument for template parameter '<Unknown>', expected a class template error C2976: 'has_result_impl' : too few template arguments seems I can't make VC to accept an unspecified template type as a template template parameter. Is there any known workaround for this situation I can implement to make this traits works in VC 9 ?

4 4

libraries dependencies
by Konstantin Litvinenko 10 Feb '09

10 Feb '09

I am working on a "yet another" build tool :) and as part of performance testing I am doing boost modularization. Boost was chosen because I work with it more then 5 years and it big enough and known to me. Modularization of boost 1.34.1 was successful and 31 (not all yet) libraries was tested. That was easy. But when I tried to modularize boost 1.36.0 I faced circular dependencies that I can't break. Some old part of boost that have enormous interheader dependencies I separated in /boost/core library(mpl + preprocessor + bind + utility + many small .hpp + details). For boost 1.34.1 I decided that throw_exception.hpp must reside in /boost/core library. For 1.36.0 I decided to put it in /boost/exception because it is natural place for that functionality. But /boost/exception is dependent on /boost/smart_ptr that dependent on /boost/exception. And ooops - we have circular dependency. I can place both /boost/exception and /boost/smart_ptr into /boost/core but that seams really wrong to me. I known that some folks working on CMake build system and also need modularize boost. So my question is: Is there any plans to do refactoring/cleaning/reorganizing/... to make boost have more clean inter-libraries dependencies? Thanx

2 1

Re: [boost] [lexical_cast] A suggestion
by Vladimir.Batov＠wrsa.com.au 10 Feb '09

10 Feb '09

> That's not my concern. My concern is that I don't think lexical_cast is > a particularly good interface for its main uses, which could be thought > of as "to-string" and "from-string." Dave, I am not sure what you see wrong with lexical_cast interface. Could you elaborate? I am not using lexical_cast (due to throw, no default value and the def.ctor requirement). So, I still keep using the analog I wrote a while back and well before I ever heard of lexical_cast. Even though I wrote it independently, the interface happened to be very close: namespace aux { namespace string { template<class Type> std::string from (Type const&); template<class Type, class String> bool is (String const&) throw(); template<class Type, class String> Type to (String const&); template<class Type, class String> Type to (String const&, Type const&); } } That is, string str = aux::string::from(-1); int i1 = aux::string::to<int>(str); // throw int i2 = aux::string::to<int>(str, -1); // no throw As you can see it is pretty close to lexical_cast. > ... > I just don't think lexical_cast is the interface we need for most > convenient string conversions. It might be the case. However, I do not see any other practical suggestions that we could act on. Therefore, in the end we end up with nothing at all... again. That's been dragging for far too long. > ... > Maybe so, but I don't think lexical_cast is all that well-designed for > convenience to begin with, and tacking on little convenience features > isn't likely to yield a very clean interface. I am not that concerned about the internal design as it can be worked on and improved without rush behind the interface. If it is the interface that is the issue, then let's look at it. Any suggestions? So far, I do not see people arguing against that proposed "extension" offering anything practical in return. That is not constructive as people end up with nothing at all. I am not counting the <optional> suggestion as it seems as an overkill and it still has the default-constructability requirement. Thanks, Vladimir.

4 9

call_traits<SomeEnum>::param_type
by Leo Landa 10 Feb '09

10 Feb '09

Good day to everyone! Is there some reason why call_traits<SomeEnum>::param_type evaluates to be the const_reference (const SomeEnum&) instead of value_type (SomeEnum)? I can't figure out if its an easily fixable mistake in the library or a result of some consideration that's not quite obvious. Any advice is greatly appreciated. Leo.

1 0

[1.38] Beta release of PDF documentation (and some help needed).
by John Maddock 10 Feb '09

10 Feb '09

Folks, SVN commit 51104 to trunk provides the basic support for building all the Boost libraries that can be as PDF's: * improved fo.xsl stylesheet, * tweaked individual Jamfiles so they find their images etc when being built as a PDF, * adds doc/pdf/Jamfile.v2 to build all boost libraries that can be as individual PDF's. Beta builds of the PDF's are available for download from http://boost.cowic.de/rc/pdf/ includes the libraries and tools: Accumulators Algorithm/String Asio Bimap Bind ConceptCheck Config DateTime ForEach Function Functional/Hash Interprocess Intrusive Iterator Lambda Logic Math/Complex Math/Octonion Math/Quaternion Math/GCD Math/Special functions and Distributions Numeric/Conversion (currently has a build problem, not on ftp site) Optional (currently has a build problem, not on ftp site) Proto PtrContainer Pythod/Tutorial Range Regex ScopeExit Signals Spirit/Phoenix StaticAssert Thread (currently has a build problem, not on ftp site) TR1 TypeTraits Typeof Units Unordered Variant Xpressive BoostBook (currently has a build problem, not on ftp site) Boost.Jam Boost.Build Quickbook. I'd be grateful if all the Boost library authors that are using QuickBook/BoostBook/DocBook could take a look at their PDF's and check that they're OK, users too if you're willing! Also if anyone would rather that their library wasn't included in this build please speak up now - eventually the plan is make these available as a sourceforge download. The following default build options have now been added to the fo.xsl stylesheet customization layer, let me know if anyone is violently opposed to these: * No indent on body text (we need all the horizontal space we can get for code blocks). * Left and right page margins 0.5in - a little small, but as above we need all the space we can get. * Paper type is A4 - it's an ISO standard, and just a little smaller than US letter, so should print OK on both. * Draft mode is turned off so we don't try and download draft.png just in case. * SVG graphics are used for admonishments. * Default path to search for images (if not overridden in a library's Jamfile) is the SVN repository: allows most (but not all) libraries to be built as PDF's without having to change their Jamfiles. Known TODO's ~~~~~~~~~~~ * Some of the PDF's are badly named: for example the python tutorial is simply "tutorial.pdf", Phoenix is "users_manual.pdf" and Boost.Build is "standalone.pdf". Anyone know how to get Boost.Build to rename a file or else change the name of Boostbook target? * The libraries Conversion, Optional and Thread do not currently build as PDF's - their XML is invalid, looks like an easy fix though - just tweak their usage of hyperlinks at global (i.e. not in a section) scope. I think I can make the changes for this one if their authors agree. * The BoostBook documentation doesn't build as a PDF - Lots of invalid XML - this one looks much harder to fix. I need some help with this one. * Currently only RenderX's XEP FO processor will build all the docs correctly, Apache FOP is *still* not mature enough :-( * There is currently no way to detect overflow of content on the right margin (usually caused by over-long code blocks), ideally this would be made a build error. I've no idea how to achieve this - the things I've tried so far don't seem to work :-( Anyway thanks for your attention, and I'll look forward to your feedback, as well as this list, there is a Wiki site here https://svn.boost.org/trac/boost/wiki/BoostDocs/PDF to track progress, Regards, John Maddock.

11 30

nested BOOST_FOREACH and -Wshadow
by Dustin Spicuzza 10 Feb '09

10 Feb '09

Hey, I really enjoy using BOOST_FOREACH on containers, saves a ton of typing. However, one semi-annoying problem that I've ran into is that nesting instances of BOOST_FOREACH causes the gcc argument -Wshadow to complain quite a bit. A useless example of this behavior is as follows: #include <vector> #include <iostream> using namespace std; #include <boost/foreach.hpp> int main() { vector < vector <int> > array; BOOST_FOREACH( vector<int>& i1, array) BOOST_FOREACH( int i2, i1) cout << i2; } And you get the following warnings: g++ -Wshadow shadowtest.cpp -o shadowtest shadowtest.cpp: In function ‘int main()’: shadowtest.cpp:13: warning: declaration of ‘_foreach_col’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here shadowtest.cpp:13: warning: declaration of ‘_foreach_cur’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here shadowtest.cpp:13: warning: declaration of ‘_foreach_end’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here shadowtest.cpp:13: warning: declaration of ‘_foreach_continue’ shadows a previous local shadowtest.cpp:12: warning: shadowed declaration is here Now, I know that some people don't believe in getting rid of warnings just for warnings sake, but the fix for this would be extremely trivial and useful (given the amount of noise that it generates) -- just add a new macro, BOOST_FOREACH_NESTED, which has a third parameter denoting the level of nesting. That parameter would be token-pasted onto the end of the variable name, and get rid of the warnings. One could define up to N more macros of the form BOOST_FOREACH_NESTED_N that get rid of the third parameter, by calling that macro appropriately. This wouldn't break any existing code, and would allow those that choose to get rid of the warnings. There are a number of arguments against such a change: (a) -Wshadow is gcc specific and isn't enabled by default, (b) If you don't like the warning, don't nest BOOST_FOREACH statements, or don't use -Wshadow. However, my feeling (and this is probably just a matter of personal preference) is that given the triviality of the fix, theres no reason to not fix it. Granted, I could easily just make my own and stick it in a header file, but it seems like it would make more sense to be in boost itself. I could create a patch and post it if so desired. Thanks! Dustin -- Innovation is just a problem away -- Innovation is just a problem away

8 10

[MPI] Dynamic linking on Windows - mpi_datatype_cache() unresolved means BOOST_IS_MPI_DATATYPE unusable?
by Pete Bartlett 09 Feb '09

09 Feb '09

Dear all, It looks like boost::mpi::detail::mpi_data_type_cache() (in boost/mpi/detail/mpi_datatype_cache.hpp) is missing a declspec declaration, causing unresolved external symbols when trying to give a specialization of is_mpi_datatype. Is my use case (Windows, dynamic, "simple" types that qualify for is_mpi_datatype) unusual so that this hasn't been picked up before? Or am I missing something obvious? Thanks in advance for any help Pete

1 0

[lexical_cast] A suggestion
by Vladimir Batov 09 Feb '09

09 Feb '09

I use boost::lexical_cast quite a bit. Possibly due to specifics of my task I constantly stumble upon two things: 1. It throws if/when conversion fails; 2. It requires the 'Target' class to be default-constructible. I'd like to suggest extending the existing template<class Target, class Source> Target lexical_cast(Source const& arg) interface with template<class Target, class Source> Target lexical_cast(Source const& arg, Target const& failure_value) The behavior of the latter would be to return the 'failure_value' if/when the conversion fails. That communicates the fact of the conversion failure differently (without an exception thrown), i.e. its usage would be as following: int value = boost::lexical_cast(some-string, -1); if (value == -1) conversion failed. In fact, my usage pattern is such that I often do not even need to check the success of the conversion -- if the conversion fails, the supplied failure/default value is returned/used and proceeded with. Secondly, the proposed lexical_cast requirements would be looser -- no need for the default-constructibility of the Target, only the copy-constructibility (as already required anyway). For that the current lexical_cast implementation if(interpreter << arg) { Target result; if (interpreter >> result) return result; } throw_exception(bad_lexical_cast(typeid(Source), typeid(Target))); return Target(); // normally never reached (throw_exception) would change (for the proposed interface) to something like if(interpreter << arg) { Target result(failure_value); if (interpreter >> result) return result; } return failure_value; I am not sure how much value such an interface extension might have for others but for my usage pattern the benefit would be quite visible as the majority of our classes are with no default constructors and handling conversion-failure exceptions is quite a hassle... not to mention that for whatever guided/misguided reasons exceptions are virtually banned for our mission-critical development. Best, V.

14 40

An extension to boost::variant
by Chris Hamilton 09 Feb '09

09 Feb '09

While boost::variant is very capable at what it does, there is one thing it doesn't do (and maybe with very good reason, which I'm sure somebody on this list will be capable of pointing out to me if this is the case ;) Anyhow, boost::variant requires each of the enclosed types to be assignable, which is clearly not met of a reference type. My question is this: why can't boost::variant be clever about reference data types (detected using type_traits is_reference), and internally store them as pointers (type derived by using type_traits remove_reference). The outside API (assignment, output streaming, visitation, comparison, etc) could still treat the object as a reference. The reason I want this, is to have a nice String variant, that encapsulates the various forms a string can take in a current project: std::strings, char*'s, and std::string* and boost::shared_ptr<std::string>. I want functions to be able to handle all of these types transparently by using variants as the argument types. Allowing "const std::string&" as a variant type allows this to be done while not requiring a wasteful string copy. Are there any caveats to this that I should be aware of? (I have a small custom variant class implementing this, and it appears to work well. It's not as 'full fledged' as the boost::variant class, but the approach I've taken could surely be grafted on to boost::variant.) Cheers, Chris Hamilton

2 2

1.38.0 release done ?
by Stefan Seefeld 09 Feb '09

09 Feb '09

While I'm casually reading this ML, I notice some ongoing discussion concerning the 1.38.0 release. Looking at the boost.org website, I trip over the 1.38.0 release announcement, and I wonder whether I just missed the 1.38.0 announcement here on the list, or whether someone mistakenly announced a release-candidate for a final release. Could anybody clarify please ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 2

[graph]
by Andrew Sutton 09 Feb '09

09 Feb '09

Update on the BGL. I've just ported my SOC work en masse from 2007 to the BGL trunk. New features include: * [un]directed_graph classes - wrappers around adjacency lists. These serve as introductory classes to help with prototyping. They also try to hide all of the problems with vertex indices and property maps - as in every algorithm requires vertex maps, but only VerteSet == vecS provides them. * degree_centraility - algorithms for computing the degree centrality of vertices in a graph. Includes measures of influence and prestige. * closeness_centraltiy - algoritghms for computing the closeness centraility (based on SSPs) for vertices in a graph. * geodesic_distance - Computes the small-world and mean geodesic distances of graphs. * eccentricity - Algorithms for computing eccentricity, and the radius and diameter of the graph. * clustering_coefficient - Returns the clustering coefficient of a vertex or the average CC for the entire graph. * core_numbers - Partitioning of a graph into cores based on vertex degree (from David Gleich) * all_cycles - Find and visit all cycles in a graph (Tiernan) * all_cliques - Find and visit all cliques in a graph (Bron & Kerbosch) * exterior_properties - A new framework for helping define exterior properties (and property maps) for graphs. New graph concepts: * VertexIndexGraph - any graph for which get(vertex_index, g) is valid * EdgeIndexGraph - any graph for which get(edge_index, g) is valid Since nearly every algorithm requires a vertex index map in one way or another, these may as well be concepts. Also, its a convenient documentary artifact that lets you write, "If your graph is not a *IndexMap, then you must provide an index map as an exterior property." Documentation for these features is forthcoming. Its part of my project to (finally) migrate the BGL docs over to quickbook. There are tests for most of these features - some are in progress - others are woefully inadequate and under development. Since I'm generally pretty busy, these will probably materialize slowly. I'm aiming at 1.40. Questions? Comments? Andrew Sutton andrew.n.sutton(a)gmail.com

3 2

[thread|interprocess] Boost.Synchro: Towards a generic view of synchronization mechanisms
by vicente.botet 09 Feb '09

09 Feb '09

Hi, Currently there are two libraries defining mutex, condition variables and locks in Boost (Boost.Thread and Boost.Interprocess), which have similar interfaces but with some differences. This has as consequence that we can not interchange them. One of the reasons is that we are not working with concepts, and algorithms. Both boost::mutex and boost::interprocess_mutex are models of the same Lockable concept, but not because they share a common syntax but because they share a common semantics. Can we see a binary_semaphore as a Lockable? Well, usually a binary_semaphore will define operations such a post and wait, so binary_semaphore do no share the common syntax as boost::mutex and boost::interprocess_mutex. On the semantic side wait can be assimilated to lock and post to unlock. By the way, there are also other syntactical differences between the Boost.Thread and Boost.Interprocess classes. So how can we write gerenic code that can be used with every model of the concepts. The idea consist in switching from the OO paradigm to the functional paradigm. We found the same approach Boost.MPL and Boost.Fusion between others. So instead of requiring that a model of the concept Lockable defines the member functions lock and unlock, we require that the functional expressions lock(m) and unlock(m) are well founded. A generic Synchro library can define a default implementation that forwards to the member function. namespace synchro { template <typename Lockable> void lock(Lockable& lockable) { return lockable.lock(); } } Now we can overload the lock function on a binary_semaphore as namespace synchro { void lock(binary_semaphore& sem) { return sem.wait(); } } Just another example for a class template anotherLockableModel that models the Lockable concept but that with acquire/release functions. We need to overload again the lock function. namespace synchro { template< typename T> void lock( anotherLockableModel<T>& lockable ) { return lockable.acquire(); } } However, there are cases where overloads do not suffice (as described in N1295 - Partial specialization of function templates), and we need to use partial specialization of function templates. On compiler that do not support partial specialization of function templates we can use a workaround, that is, use partial specialization of class templates. The default implementation will now forward to a static function of a class which has forward to the member function namespace synchro { namespace partial_specialization_workaround { template< typename Lockable > struct lock { static void apply( Lockable& lockable ) { return lockable.lock(); } }; } template <typename Lockable> void lock(Lockable& lockable) { return partial_specialization_workaround::lock<Lockable>::apply(lockable); } } So now the user can partially specialize the class template partial_specialization_workaround::lock and define the apply function as needed: namespace synchro { namespace partial_specialization_workaround { template< typename T> struct lock <anotherLockableModel<T> >{ static void apply( anotherLockableModel<T>& lockable ) { return lockable.acquire(); } }; } } Once we have all the Lockable operations defined in this way, and do the same for ConditionVariable, we can define in a generic way unique_lock, shared_lock and upgrade_lock that works with boost::shared_mutex as boost::interprocess::interprocess_upgradable_mutex. This could leverage these libraries to define its own locks classes. Ion, Anthony, Boosters what do you think of applying this approach to get a generic Synchro library? Should the partial_specialization_workaround be applied systematicaly or it complicates things? Thanks, Vicente

2 3

[factory] Including documentation
by Rutger ter Borg 09 Feb '09

09 Feb '09

Dear all, After about 30 minutes searching and digging I found out that apparently a Boost.Factory library is accepted into Boost, and committed to trunk under Boost.Functional. Would it be an idea to include its documentation under the main documentation as well -- or is this already done in 1.38.0? Thanks, Kind regards, Rutger ter Borg

1 0

[1.38.0] Release candidate
by Beman Dawes 09 Feb '09

09 Feb '09

The release candidates are up at http://boost.cowic.de/rc/ Daniel, I'd appreciate it if you could check the docs to make sure there were no glitches. I'll hold off releasing the files on SourceForge until I've heard back from you. Thanks, --Beman

3 5

[constrained-value] Some observations and questions.
by Jeroen N. Witmond [Bahco] 09 Feb '09

09 Feb '09

Greetings, Please forgive me for intruding on the Boost Development mailing list. I'm rather new to Boost, but I'm in love with it, because IMHO it shows C++ as it should be used. :) While browsing this mailing list, I came across the review announcement[1] for the Boost Constrained Value library[2]. I like the concept, so I downloaded[3] and installed the library. I also installed file boost/utility/swap.hpp from the sandbox. I had to hack the example program[4] to get around "[boost] [utility/swap] Ambiguous overload"[5]. To get familiar with Boost and the Boost Constrained Value library, I first rewrote the example program into a Boost.Test testcase[6]. (I have tried not to disturb the documentation generated from this file, but I did not test this.) As testcase, it runs succesfully, with the hack mentioned above. (At least for me, Emacs has problems with font-lock-mode[7] on this file. The original example program does not demonstrate this problem.) In the section on Custom error policies in the example program, perhaps it should be explicitely stated that: - on entry into the error handler, constraint(new_value) will always be false. An error handler that neither changes the constraint, nor supplies a valid value can therefore throw unconditionally. - on entry into the error handler, constraint(value) will only be false during the construction of an object with an invalid value. If the error handler does not throw in this case, the library will raise signal SIGABRT (application abort requested). - the only case where the error handler can be empty is when the constraint always returns true, as in 'template <typename ValueType> class unconstrained'[8]. This code[9] illustrates these points. Next I was itching to create and more real-life use case for the Boost Constrained Value library, with special attention on improving error reporting. So I wrote four template classes[10], implementing non-positive, non-negative, positive and negative constraints over any integral type. (This code still can be improved in many ways.) These constrained integers can be declared like: positiveInteger<int> i; // Construction with value 0 would fail, BOOST_CHECK_EQUAL( i, 1 ); // so it is set to 1. They can used like teir base type. In case of constraint violations (e.g. 'i = 1;' for 'i' above), an exception is thrown, which derives from both std::logic_error and boost::exception. The std::logic_error::what() returns: Failed assert(1 <= 0); And from the boost::exception, the following information can be retrieved (slightly edited to fit the newsgroup): constrained-integer.hpp:168: In '[very long function name]': Failed assert(-1 > 0); constrained-integer.cpp:82: Constraint was defined here. See the first testcase in the Boost.Test testsuite[11] for the code that produced these messages from boost::exception. The remainder of the testsuite runs the four template classes both against fundamental types, and against classes that implement infinite precision integer arithmetic. This showed that I needed to implement 'bool operator == (const Integer & v) const' for these classes, but not for the fundamental types. As implementing this operator==() for fundamental types results in compiler errors, the implementation is present only when preprocessor symbol 'CLASS_TYPE' is defined. (My attempt to hack this in the Boost Constrained Value library source failed.) Note that no hackery is needed for the relational operators used in the constraints. Otherwise, the testsuite compiles correctly and runs almost as expected. It would appear that in the process I may have discovered a bug[12] in the mp_math library in the sandbox. One question I have is related to the requirement of the Constrained Value library that the constraint and error handler objects must be completely constructed before the constrained object is constructed. In these four template classes, I handle this by deriving my template type (e.g. nonPositiveInteger) from the constraint class and indirectly from the error handler class. The purpose is to allow these template types to be used as drop-in replacements for the types they constrain. In this context it appears to work, but I'm having second thoughts about its validity and advisability. Although it is not a Boost question, is there anybody who wants to comment? One thing that has gotten me completely stumped is deriving my own template class from constrained_value::unconstrained. Whatever I try, I get the weirdest of compiler error messages. See the bottom of [10] and [11] for my latest attempt in the section guarded by '#ifdef DO_UNCONSTRAINED'. I must be missing something obvious. Also all other comments will be appreciated. Regards, Jeroen. PS: All files referenced in this email and authored by me are released under the Boost Software License, Version 1.0[99]. Note however that this code is not of release quality. [ 1] http://lists.boost.org/Archives/boost/2008/12/145581.php [ 2] http://student.agh.edu.pl/~kawulak/constrained_value/index.html [ 3] http://rk.go.pl/f/constrained_value.zip [ 4] file libs/constrained_value/doc/src/examples.cpp in [3]. [ 5] http://lists.boost.org/Archives/boost/2007/10/128494.php [ 6] http://www.xs4all.nl/~jnw/boost/constrained-value/test-constrained-value.cpp [ 7] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510475 [ 8] file boost/constrained_value/unconstrained.hpp in [3]. [ 9] http://www.xs4all.nl/~jnw/boost/constrained-value/understanding-ignore.cpp [10] http://www.xs4all.nl/~jnw/boost/constrained-value/constrained-integer.hpp [11] http://www.xs4all.nl/~jnw/boost/constrained-value/constrained-integer.cpp [12] http://lists.boost.org/boost-users/2009/01/43824.php [99] http://www.boost.org/LICENSE_1_0.txt

2 1

[constrained] constrained_vector
by Neal Becker 09 Feb '09

09 Feb '09

I'm interested in something like constrained, but applied to a vector of values. The case I'm interested in is a homogeneous vector of bounded int values, with bounds set at runtime. It is trivial to have a vector<bounded<int> >, but this would not be space efficient in the case where the policies, bounds on all the values are the same. I'm thinking that maybe some parts of constrained (such as policies) could be reused, independent of the rest of constrained. Has anyone looked into the idea of constrained vector?

3 4

[1.38.0] beta 2 release candidate
by Beman Dawes 09 Feb '09

09 Feb '09

The beta 1 release candidate from earlier in the week had enough issues that I decided not to push it out to sourceforge. Most (all?) of those issues have been corrected, and a new release candidate is up at http://boost.cowic.de/rc/ If no showstoppers surface I plan to move this beta to sourceforge tomorrow (Friday) and announce it here, the users list, and the announce list. The final 1.38.0 release would then come about week later. There are pending bug fixes for Boost.Python and Boost.Asio that are not in the beta but Dave and Chris are planning to have ready for the final release. --Beman

10 28

[constrained_value] Review version
by Robert Kawulak 09 Feb '09

09 Feb '09

Hi all, I've made some minor changes to the Boost Constrained Value library: - reorganized the structure of header files, - renamed saturating/saturating_int into clipping/clipping_int, - using boost::swap where applicable (if you don't have it, you need to get it from http://svn.boost.org/svn/boost/branches/release/boost/utility/swap.hpp) - made no_constraint policy public, - now the stream operators are not defined if BOOST_NO_IOSFWD macro is defined, - fixed identifiers containing "__" (not allowed by C++), - fixed minor language errors in the docs. The library is ready for the formal review, which starts this monday (1.12). It is only missing the detailed regression tests, which will be added after the review. Currently the examples file (libs\constrained_value\doc\src\examples.cpp) can be used instead -- it uses most of the functionality of the library and should compile and run returning 0. As usually, the code and documentation can be downloaded here: http://rk.go.pl/f/constrained_value.zip The documentation is also available online here: http://rk.go.pl/r/constrained_value Any comments and problem reports for platforms that has not been tested yet are very welcome. Best regards, Robert Kawulak -=##############=- "I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." - Albert Einstein

3 4

[constrained_value] serialization
by Neal Becker 09 Feb '09

09 Feb '09

constrained_value does not currently support serialization. 1. Should it be added to the lib? 2. What would be a suggested implementation?

3 5

[threadpool] new version - supporting future library (C++0x) from Anthony Williams
by k-oli＠gmx.de 09 Feb '09

09 Feb '09

Hello, I've uploaded a new version of boost.threadpool (v17) at http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-…. It uses the future implementation of Anthony Williams (C++0x - available at http://www.justsoftwaresolutions.co.uk/files/n2561 future.hpp). Please save it as file 'future'. best regards, Oliver

3 10

[interthreads] Library under development v0.4
by vicente.botet 09 Feb '09

09 Feb '09

Hi, I have just released the version 0.4, which includes since my last publicly announced version 0.3.0: Version 0.4.0, Fevrary 8, 2009 Improvements + bug fixes New Features: * New free functions for all the AsynchronousCompletionToken operations, providing a higher degree of freedom. * Missing have_all_values(), have_all_exception() and are_all_ready() functions on AsynchronousCompletionToken fusion tuples. * get_all: getting all the values from a tuple of AsynchronousCompletionToken works now. * fork_after overloaded for a single dependency * wait_all overloaded for a single ACT. * wait_for_all evaluate one of its elements on the current thread * No need to use wait_and_get() on thread_specific_shared_ptr<> to synchronize with the decoration if the thread is created using a AsynchronousExecutor decorator. In this case the synchro is done before returning the AsynchronousCompletionToken. See the tutorial and the mono_thread_id example. Fixed Bugs: v0.2#1: ae::get_all do not work yet. get_all() do not work because fusion transform sequence function can not take non const sequences. I have emulated it using set_all() and a transformation for a tuple of _ACT to a tuple of result_type. v0.3.1#1: keep alive mechanism crash when setting set_on_dead_thread() before enabling the mechanism. This was due to the fact that there were no default data for the backup. v0.3.1#2: keep alive mechanism do not detect dead threads. We need to reset the counters only when the period is 0. v0.3.1#3: The set_on_dead_thread() setting is not recovered by embeeding kep_alive enablers/disablers. The problem is that the on_dead() the function and the thread pointer were stored on the backup. It is enough to store them on the thread_keep_alive_ctx and make the functions thread_safe. Version 0.3.1, January 25, 2009 bug fixes Fixed Bugs: v0.3#3: scheduler::do_test_fork_after_wait do not work yet. To solve this issue it enough to define boost::move for tp::task v0.3#2: scheduler::do_test_fork_after_get do not work yet. To solve this issue it enough to define boost::move for tp::task v0.3#1: scheduler::do_test_wait_for_any do not work yet. Not reproductible v0.2#2: Some trouble with the use of tp::pool directly, use scheduler instead. Four issues. The parameter to fork on tp:pool was a const F& instead of a F. Direct use of fork_all resolved for the other AsynchronousExecutor by ADL, which could not be the case for the tp::pool. fork specialization for tp::pool incorrect. use of the default handle instead of asynchronous_completion_token traits class For those who don't know the library yet here are some of its features: * An asynchronous execution framework working with AsynchronousExecutor and AsynchronousCompletionToken. It includes some generic functions working on AsynchronousExecutor and AsynchronousCompletionToken concepts: * fork and fork_all to execute functions asynchronously. * fork_after: request an AsynchronousExecutor to execute a function asynchronously once each one of AsynchronousCompletionToken in the dependency tuple parameter are ready. It is similar to the async_with_dependencies proposed Peter Dimov. * generic wait_for_all, wait_for_any to execute asynchronously functions and wait for the completion of all or any of them. * generic get, join, ... free functions to synchroyze on an AsynchronousCompletionToken * generic get_all, join_all, ... free functions to synchroyze on multiple AsynchronousCompletionTokens * Some AsynchronousExecutors and AsynchronousCompletionTokens models * basic_threader: can be seen as a thread factory executing asynchronously a function on the returned thread. * launchers: Lanchers can be seen as a future factory executing asynchronously a function on a hiden thread. * threader/joiner: A Threader runs a unary function in its own thread. A Threader can be seen as a Joiner factory executing asynchronously a function on a thread encapsulated on the returned Joiner. The joiner is used to synchronise with and pick up the result from a function or to manage the encapsulated thread. * tp::pool and tp::task customization as an AsynchronousExecutor and an AsynchronousCompletionToken respectively. tp::pool can be seen as a tp::task factory executing asynchronously a function on a pool of threads. a generic asynchronous_executor_decorator which allows to decorate the function to be evaluated asynchronously. * Some thread extension * A thread_decoration class allowing to define setup/cleanup functions which will be called only once by thread (if the thread function is decorated with thread_decorator): setup before the thread function and cleanup at thread exit. It is used together with asynchronous_executor_decorator * A thread_decorator/thread_decorate class/function which decorate a thread function in order to call the setup and the cleanup of all the thread_decorations. * A thread specific shared pointer which is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. * A thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. The library is available at Boost Sandbox: https://svn.boost.org/svn/boost/sandbox/interthreads and Boost Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=intert… Includes every thing on the Sandbox + Html documentation + Boost.Futures + Boost.ThreadPool adaptations I'd appreciate it if people could take a look, test it on their compiler and give me some feedback. Best regrads, Vicente Juan Botet Escribá

1 0

[1.38][any][thread] Release notes
by Daniel James 08 Feb '09

08 Feb '09

Hi, I've added release notes for these libraries. I don't really know the story behind these changes, so if the libraries' maintainers or an interested user wants to check them, they're at: http://beta.boost.org/users/news/version_1_38_0#version_1_38_0.updated_libr… thanks, Daniel

5 5

[1.38] CMake support added to release branch?
by John Maddock 08 Feb '09

08 Feb '09

I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened? John Maddock.

8 11

function dispatch mismatch in graph_traits
by Sandeep Gupta 08 Feb '09

08 Feb '09

Hi, I am having trouble making leda_graph wrapper for GRAPH<vtype, etype> class. In leda_graph.hpp the wrapper is defined as template<class vtype, class etype> ... vertices(const leda::GRAPH<vtype, etype>& g) { do_something; } Given this definition the right (and only way i think) to invoke it by expression vertices<vtype, etype>(G) My problem is that all internal graph routines invoke the function by expression vertices(G) I would appreciate any ideas about how can i redirect vertices(G) to vertices<vtype, etype>(G) where vtype = vrec etype = erec G = leda::GRAPH<vrec, erec> I am afraid that i might have to rewrite a wrapper for specifically leda::GRAPH<vrec, erec>. Can this be avoided. Thanks sandeep

2 2

Review Request: Boost.Log
by Andrey Semashev 08 Feb '09

08 Feb '09

Hi, I'd like to ask for a formal review for the Boost.Log library. The archive with the library source code, tests and docs is available in the Vault: http://tinyurl.com/cm9lum The online docs are also available on the SourceForge page: http://boost-log.sourceforge.net The latest code snapshot can be downloaded from CVS on the SourceForge project page: http://sourceforge.net/projects/boost-log

1 0

[1.38.0] branches/release frozen
by Beman Dawes 08 Feb '09

08 Feb '09

I plan to do the actual release Sunday. Please make no further commits to branches/release. If there are any known showstoppers, please let me know right away. Thanks, --Beman

6 12

[statechart] rebind -> exception_translator error
by k-oli＠gmx.de 08 Feb '09

08 Feb '09

Hello, I get following compile time error (using gcc version 4.3.1 on Debian/Lenny) for a test async_state_machine: /opt/boost/include/boost-1_37/boost/detail/allocator_utilities.hpp:149: error: no class template named 'rebind' in 'class boost::statechart::exception_translator<boost::statechart::exception_thrown>' regards, Oliver

2 1

build system testing
by Neil Groves 08 Feb '09

08 Feb '09

Hello, I have noticed that work is going ahead to introduce CMake, and possibly SCons build systems alongside bjam. Does this not introduce an explosion in required testing combinations, and is this already being addressed? I fully appreciate the attraction of adding CMake, but would like to ensure we do not add too many build systems due to the potentially excessive requirement on library developer to install a plethora of tools, and perform an enormous amount of testing. I wonder if a static analysis tool might be able to help determine the consistency of bjam to the other build systems. Anyhow, I haven't seen much discussion about testing, and if it's not tested it's probably broken! (At least if I've written it!) Regards, Neil Groves

4 3

[random] Patch for ticket 2703
by Steven Watanabe 08 Feb '09

08 Feb '09

AMDG In lagged_fibonacci_01, the overload of seed that takes a pair of iterators does not always detect the end of the range correctly. The attached patch fixes this and adds a test case. Ok to commit? In Christ, Steven Watanabe

2 1

[format] please add operator String()
by Thorsten Ottosen 08 Feb '09

08 Feb '09

Hi, In code like this: std::string columns() const { return (boost::format("%7s, %7s, %7s, %7s") % "testCost" % "optimalEcr" % "efficiecyEcr" % "testCostEcr").str(); } it is very annoying to have to put () around the whole expression and then call .str() (Just imagine that we are creating a string on the fly to a function). Therefore I suggest that we add operator string_type() const { return str(); } to the interface of basic_format<>. Any comments? -Thorsten

7 8

FW: [filesystem] : basic_path : Feature request
by Rob 07 Feb '09

07 Feb '09

> These seem like reasonable requests, although I'd have to check the > std::back_inserter to be 100% sure. > I have checked this using a wrapper around path as follows template<class String, class Traits> struct rob_basicpath : boost::filesystem::basic_path<String, Traits> { typedef string_type& reference; typedef const string_type& const_reference; inline void push_back(const_reference path) { *this /= path; } }; This allowed me to use the following code as expected (which strips . characters from the path) const boost::filesystem::path path("dir1/./dir2/./dir3"); rob_path rpath; std::remove_copy(path.begin(), path.end(), std::back_inserter(rpath), "."); > Note however that path has some but not all of the characteristics of > a standard container. I'd want to see persuasive use cases for adding > functionality - just making path more like a std container without > good reason is likely to lead to interface bloat without offsetting > benefits. My reasoning for this is as follows: 1. path is wrapper around a string, which is what would be used in the absence of path object. String supports this interface and using path should not be a step backwards. 2. A variety of tasks I envisage on a path can be neatly and succinctly implemented using std algorithms. In particular, I have several uses for copy or remove_copy to create similar paths with a slight difference. The ability to use a back_inserter allow paths to be built up from other paths or any container of strings. Without this, my solution for removing '.' involved the same code but I had to insert into a vector first and later iterate through this to create the new path. > A use case would make this [pop_back()] more compelling. My code above to remove '.' was part of a 'canonicalize' function which removed both '.' and '..' where possible. (This may be a candidate for a convenience function within the library?) My solution was as follows std::vector<std::wstring> parts; BOOST_FOREACH(std::wstring part, path) { if (L"." == part) continue; if (L".." == part && parts.size() && L".." != parts.back()) parts.pop_back(); else parts.push_back(part); } boost::filesystem::wpath simple; BOOST_FOREACH(std::wstring part, parts) simple /= part; return simple; Whilst this is IMO reasonably elegant, I still have the extra step of building my new path in a vector, then creating the path from this. The addition of pop_back() to path would allow the path to be built up without the vector. Given that path allows the path to be considered as a container of path elements, I would like to see this extended. A reverse iterator would be nice to step back from the given path up to the root. Pop_back would equate to stepping back to the parent directory and seems a useful feature. Given that there exists a function to remove the filename, this also seems to be relatively easy to implement (as an inlined function?) I have only recently discovered filesystem::path and, given my current project's requirements for directory manipulation, this is a fantastic help. Cheers Rob

5 5