- Boost - lists.preview.boost.org

Reflexion in boost.
by Alejandro J. 02 Dec '08

02 Dec '08

I think push reflexion into the boost library, i need the new branch.this process i try doing in the next mount., sorry for my english. Alejandro jaime. _________________________________________________________________ Color coding for safety: Windows Live Hotmail alerts you to suspicious email. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety…

1 0

Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
by Vladimir Batov 02 Dec '08

02 Dec '08

Andy, Thank you for taking the criticism the right way and my apologies if some of my comments sound(ed) somewhat harsh. It is never my intention. I won't be addressing the points below directly as some issues I raised are petty (and I somewhat wish I did not raise them). I admit I felt uneasy with the proposal but could not pin-point what it was. I'll try again. Background: We are in our project currently using uuid facility heavily and very dependent on it. The version we use (from memory) is something like (it's not necessarily exactly what we use and I'll omit some scaffolding and stick with the basics): struct uuid : public std::string { typedef std::string base; uuid() : base(generate()) {} explicit uuid(string const& s) : base(s) {} static uuid null() { return uuid(std::string()); } private: std::string generate(); }; On Linux the generate() function calls uuid_generate(). No one (in our project anyway) can be bothered choosing between uuid_generate_random() or uuid_generate_time() -- uuid_generate() takes care of the guess work and picks the best available. The same on Windows -- it'll probably be UuidCreate()&UuidToString(). Given that uuid above is merely a wrapper over OS facilities, we get known behavior, we are guaranteed "support" and an automatic "upgrade" if/when the standard changes or a new better algorithm becomes available. For me (a collective nebulous "me") to switch to your boost::uuid it has to provide something to win me over. Let's see what that might be. Does boost::uuid provide superior implementation? Maybe. If it is, that was not spelt out sufficiently visibly for me to pick up in the documentation. Therefore, as it is now the answer regretfully has to be 'no'. Does boost::uuid provide superior interface? That issue might get very subjective and personal. Therefore, I'll re-focus on if boost::uuid is user-friendlier. Maybe but I doubt it as an ordinary user does not want to be bothered choosing between algorithms. If uuid_generate() and UuidCreate() can make that choice for me, it is good enough for the overwhelming majority of uuid applications. Therefore, the answer seems again 'no'. Does boost::uuid provide superior support and a upgrade path? With all due respect I have to say 'no' again as your support (no matter how enthusiastic it is) cannot compete (on industrial/commercial scale) with vendor-backed support. uuid_generate(), UuidCreate() as printf() come with the system. One has to have really serious reasons to use something else instead. Does boost::uuid provide superior documentation? Well, my impression is that it is 'no' again. What boost::uuid does immediately entice an ordinary user with then it is Boost reputation. However, in all honesty it's not boost::uuid property per se but the reputation for quality of the Boost libraries built over those many years. In this thread I hear some people say "it's OK to ship". I disagree. Every new library has Boost reputation to uphold. It takes time to build such a reputation. It does not take long to lose it -- a couple of just "OK to ship" libraries will probably do. I'd probably be more comfortable if boost::uuid took the approach of boost::thread of providing consistent interface across many platforms via re-use of the functionality provided by the OS (when available) rather than duplicating it. Then though I'd expect the interface to be given considerably more thought. As for the interface I'll express my view to one of your comments below. > I would not want the default constructor to generate a uuid. I don't > want users to pay for that if they don't want it. Some use cases will > not require generating uuids, only using them. I have to disagree. I believe that the overwhelming majority of cases falls into the following category -- "I introduce something when/because I need that something". That is, by Foo foo; std::string str1; std::string str2(params); uuid id1; uuid id2(param); I create valid instances. Say, 'str1' is empty but it is still a valid string. I create 'id1' because I need an uuid. You on the other hand use uuid id2(param); // valid instance uuid id1; // invalid instance where #1 creates a valid instance but #2 creates an invalid instance (it lacks its identifying property -- it's NOT unique). Therefore, you use the same (visually and behaviorally) creation mechanism to achieve *different* results. From the user perspective it is inconsistent and likely unexpected. The case you are catering for with uuid() is not mainstream but quite the opposite -- the user introduces something that he does *not* want. Such case should be handled explicitly with the user actually spelling out what he means like Foo::Foo() : uuid_(boost::uuid::null()) // initially invalid {} Best, Vladimir.

4 3

Boost namespace abreviations
by edam 01 Dec '08

01 Dec '08

Hi there, I just wanted to hear the boost community's thoughts on abbreviating boost's namespaces. According to Boost's library naming conventions (http://www.boost.org/development/requirements.html#Naming_consistency) this is strongly discouraged, and with good reason -- having clearly (and consistently) named namespaces is a good thing! Having used boost for a (mere) couple of years now, though, I've started to find its namespaces a bit unwieldy. I try to avoid going "using namespace" (for a few reasons, nicely summarised here: http://dev.lsstcorp.org/trac/wiki/DiscussCodeStandards) and I can't bring myself to go down the route of announcing to the compiler that I will be "using ..." specific symbols from whichever namespace either. So I am left with having to explicitly specify the namespace of each symbol, like this: std::cout << std::setw( 2 ) << std::setfill( '0' ) << hours; While this requires more typing, I prefer it to the alternatives. As a boost user though, I find this becomes a bit more of a pain. Boost's namespaces, whilst well named, are a lot to keep typing out! Here's a quick example: boost::posix_time::time_duration foo = boost::posix_time::hours(2); Multiply this by a thousand lines of boost-using code and you've got a lot of typing! I wondered if there would be any interest in a boost abbreviations header that, if included, would provide abbreviated names for boost's namespaces. Something along the lines of a boost/abrv.hpp: // this is an incomplete example namespace bst = boost; namespace boost { namespace gd = gregorian; namespace pt = posix_time; namespace dt = date_time; } This would allow the developer to shorten the above example code to bst::pt::time_duration foo = bst::pt::hours(2); in this case saving a full 18 characters! Multiply this by 1000 lines of code and you may save some finger-ache. What I'm proposing sounds terrible, I know, but if you consider that users would "opt-in" to this by including the abbreviations header (meaning it wouldn't affect existing users), I wondered if there would be any merit in it? I'm expecting a lot disapproval to this idea, but I thought I'd ask what people think anyway. Please don't shoot me down too much -- this is my first post to the boost mailing list! :o) Regards, Tim. -- edam - www.waxworlds.org/edam

5 4

boost::regex problem with escaped parenthesis
by Kumar, Anurag 01 Dec '08

01 Dec '08

Hello, While trying to match the escaped "(" I am facing problem. Following is the code snippet : std::string stdString = "abc(def)ghi"; std::string bExpression = "c\\(def\\)g"; // Creating the expression boost::regex boostRegEx ( bExpression, boost::regex::extended ); // my match function boost::smatch boostMatch; std::string::const_iterator itr_begin ( stdString.std().begin()); std::string::const_iterator itr_end ( stdString.std().end() ); bool b_match = false; // Match flags used boost::match_flag_type matchFlags = boost::regex_constants::match_default | boost::regex_constants::match_not_dot_newline | boost::regex_constants::match_single_line; // Trying to match b_match = boost::regex_search( itr_begin, itr_end, boostMatch, boostRegEx, matchFlags ); My expected result is: b_match should be "true" boostMatch should contain "c(def)g" Please help me to fix this problem. Regards, Anurag

2 1

[date_time] Internal header testfrmwk.hpp
by Andrey Semashev 01 Dec '08

01 Dec '08

Hi, There is a testfrmwk.hpp header in the boost/date_time directory. This header contains some utility to aid testing of the library and I believe is not a part of the library interface (that is, it's not in boost namespace and I don't see it documented). I don't know why the header resided in the boost/date_time directory in the first place, so I intend to move it into the test directory. Does anyone have objections? (Jeff, I hope, you're reading this)

2 2

[Boost.Thread] ids obtained from the same thread not equal
by Karp Dantax 01 Dec '08

01 Dec '08

Using boost::thread::get_id() in an executable and one of its DLLs generate different ids although the calls are made from the same thread. Until Boost 1.34.1, which used GetCurrentThreadId() to compare two boost::thread objects, it worked perfectly. I have not delved into the code, but now that the library is using thread local storage to store the current thread id, it is not working in the context mentioned above. Well, thats it. Maybe i am missing something here? []s

2 1

[Review] UUID library (mini-)review ends today, November 30rd
by Hartmut Kaiser 01 Dec '08

01 Dec '08

Hi all, the review of Andy Tompkins' UUID library ends today, November 30th. Nevertheless, it's still possible to submit a review for at least a week, as I'm not going to have time for the analysis of the review before Christmas. Thanks to all of you who submitted a review. Regards Hartmut Review Manager

1 0

Re: [boost] Breaking existing libraries
by Tomas Puverle 01 Dec '08

01 Dec '08

> Too bad, and just when I thought we were getting down to brass tacks. > Well, maybe Tom would care to weigh in on these issues; I'm still making > an effort to figure out how best to resolve them. I have been absolutely swamped in the last two days and will not have the time to write up any responses until much later today. Having said that, do you think it's worth my time? It doesn't seem really like we're getting anywhere.

3 6

RFC: Automatic indexing of quickbook/boostbook/docbook docs.
by John Maddock 30 Nov '08

30 Nov '08

I've just committed a new tool to the sandbox under tools/auto_index which helps automate the indexing of quickbook/boostbook/docbook documentation. Obviously the tool is biased toward C/C++ code documentation, as among other things it can scan C/C++ headers looks for definitions of classes/typedefs/macros/functions which should be indexed. The actual index can be produced either by the final XSL transform, or by auto_index itself (ie using regular docbook markup for the index), the former is better for PDF/print docs as it allows page numbers to be inserted, the latter works better for html docs, and is also faster (thankfully - the XSLT index generation code is glacially slow). There are some examples taken from type_traits and Boost.Math here: http://svn.boost.org/svn/boost/sandbox/tools/auto_index/example/readme.html Some rather basic documentation for the tool itself is here: http://svn.boost.org/svn/boost/sandbox/tools/auto_index/doc/html/index.html note that currently there is no Boost.Build integration - I really need some help with that - so the tool is much harder to use than it should be. Any comments, especially on the usability of the indexes generated would be much appreciated! Cheers, John.

5 12

[test] minimal.hpp causing unresolved external with Intel on Windows
by Beman Dawes 30 Nov '08

30 Nov '08

The little program below compiles and runs fine on most compilers, but with the Intel compiler there is an unresolved external: test.obj : error LNK2019: unresolved external symbol "void __cdecl boost::throw_exception(class std::exception const &)" (?throw_exception@boost@@YAXABVexception@std@@@Z) referenced in function _main test.exe : fatal error LNK1120: 1 unresolved externals --Beman #include <boost/test/minimal.hpp> int test_main(int, char*[]) { return 0; }

2 4

filesystem: wrong close 0 descriptor in copy_file_api on unix
by Anton Ivanov 30 Nov '08

30 Nov '08

Hi! Seems bug in boost::filesystem::copy_file on unix. This code is wrong if ::stat call fails - it is just close descriptor with number 0 (by if ( infile >= 0 ) ::close( infile );). BOOST_FILESYSTEM_DECL error_code copy_file_api( const std::string & from_file_ph, const std::string & to_file_ph ) { const std::size_t buf_sz = 32768; boost::scoped_array<char> buf( new char [buf_sz] ); int infile=0, outfile=0; // init quiets compiler warning struct stat from_stat; if ( ::stat( from_file_ph.c_str(), &from_stat ) != 0 (infile = ::open( from_file_ph.c_str(), O_RDONLY )) < 0 (outfile = ::open( to_file_ph.c_str(), O_WRONLY | O_CREAT | O_EXCL, from_stat.st_mode )) < 0 ) { if ( infile >= 0 ) ::close( infile ); return error_code( errno, system_category ); } Fix is just changing int infile=0, outfile=0; // init quiets compiler warning to int infile=-1, outfile=-1; Patch attached. Bug https://svn.boost.org/trac/boost/ticket/2542 created. -- Yours sincerely, Anton Ivanov (ai(a)drweb.com)

2 1

[result_of] decltype and function objects
by Eric Niebler 29 Nov '08

29 Nov '08

I've noticed test failures when compiling some of boost in C++0x mode due to the change to boost::result_of to use decltype. The problem comes from function objects like this: template<class T> struct identity { typedef T result_type; T const & // <== problem here operator()(T const &t) const { return t; } }; In this (overly simplistic) example, we just want to return what is passed in. The computed type (result_type) is different than the return type of operator() ... and for a good (IMO) reason: to avoid an unnecessary copy in some cases. The idea is to accommodate usage like this: result_of<identity(BigObj)>::type i = identity()(BigObj()); It is really very important that decltype(i) be BigObj, and not BogObj const &, which would cause a dangling reference. But with the change to use decltype in boost::result_of, the dangling reference is exactly what I would get. Am I now forced to change identity::operator() return by value here? That seems sub-optimal to me. In many other potential uses of identity (e.g., when forwarding the result to some other function), the copy is totally unnecessary. -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 3

Maintenance Guidelines wiki page (Revison 8)
by vicente.botet 29 Nov '08

29 Nov '08

Hi, I have updated the Maintenance Guidelines wiki page. I have take in account the minor proof-reading modifications from Steve Watanave which I have overridden by error (thanks Steve!),and added a lot of thinks, maybe too much :) Please read this mail completely before jumping to the page. This page need to be completed and reworked. Please be free to add new sections to the page or improve the current ones directly or post your comments or suggestions to this list. Here it is the table of contents. [C] 1. Motivation [C] 2. Introduction [C] 1. User code breaking cases [I] 2. Versioning individual Boost libraries [O] 3. Deprecating features [I] 4. Cross version testing [C] 3. Documentation [O] 1. Tag Boost library with specific library version [developer] [O] 2. Make feature request for each feature [developer, user] [I] 3. Include the tracked tickets on the Release notes [developer] [I] 4. List the test cases associated to the trac system tickets [developer] [I] 5. List the dependency upon other Boost library [developer] [O] 6. Document behavior differences between release and debug variants [O] 7. Document behavior differences between toolsets [developer] [C] 4. Coding [O] 1. Don't use using directives [user] [C] 2. Avoid the use of include all features files at the /boost level [user] [C] 3. Be careful with the use of using namespace header files [developer] [C] 4. Don't overload functions that are used by the TR1 (using using)[developer] [O] 5. Avoid include-all-features files at the /boost level [C] 6. Don't refine functions overloading without ensuring the same behavior [C] 7. Avoid the inclusion of symbols at the boost or boost::detail namespace [C] 8. Avoid different external behavior depending on the variant release or debug [O] 9. Avoid to change interfaces [developer] [O] 1. Don't delete files prematurely [developer] [O] 2. Don't delete namespaces prematurely [developer] [O] 3. Don't delete classes/functions/variables prematurely [developer] [O] 4. Don't modify functions prototypes prematurely [developer] [O] 5. Remove the deprecated features on a given release [developer] [C] 5. Test [C] 1. Test headers [developer] [C] 1. Include each header files twice [developer] [I] 2. include each couple of header files in both orders [C] 3. Include all header files [C] 4. link all the header files twice [C] 2. Don't forget to test [C] 1. The implicitly generated member functions [C] 2. The removed default member functions when you declare a constructor [C] 3. The deleted (private) default member functions [C] 4. The explicit constructors [C] 5. The implicit constructors or conversions [C] 6. The const-ness of variables, function parameters and function return types [I] 3. Separate the functional test from the unit test (implementation test) [I] 4. Track regression test on the trac system tickets [I] 5. Preserve the functional test from the preceding versions [developer] [C] 6. Inspections [O] 1. Announce new library features [developer] [C] 2. Inspect the code [developer, user, RM] [C] 3. Check that every modification has been documented [developer, user, RM] [C] 4. Check that every modification has been tested [developer, user, RM] [U] 7. Developer guidelines [U] 8. User guidelines [U] 9. Release manager guidelines Tasks I plan to do: 1* Add the motivation 2* Add other examples of user code break in 2.1 3* Update the Developer, User and Release manager guidelines cross reference (7,8,9) 4* Separate on 4 pages. Main, Documentation, Coding, Test and Inspections 5* Complete incomplete guidelines [C] and improve some of them [I] Note that some guidelines applied to the developer library could be done by other people that would need SVN writtig permission. In particular the Functional Test and some documentation reports. (See below points C and E) Other points I see: A* See if the Jamfile to test the headers from Steve can be adapted to tests (Steve?) 5.1.2 Include each couple of header files in both orders B* See if the difference between source and binary compatibility is desirable (ALL) C* See if the functional test can be written by a team of interested users to don't overload the developers. These tests could in addition include multi-library tests and be stored in a directory independent from the developers one (Interested users?) D* See which configurations (deprecated or not) could be tested by the current test team. (Release Manager Team?) E* See how the following points can be automated and where this information can be included in the documentation. A separated page make possible that this task could be done by other people than the developer. (Some one knowing the Track system?) 3.3. Include the tracked tickets on the Release notes 3.4. List the test cases associated to the trac system tickets F* See how the dependencies between libraries can be automated (Release Manager Team?, CMAKE project?) 3.5. List the dependency upon other Boost library In order to know if I'm going on the right direction, I would like the interested people reply to this post stating for each section, if it is OK[O], must be completed[C]/improved [I], must be updated [U], must be removed [R] and of course any idea is welcome. You can access it directly at "https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines" or at "https://svn.boost.org/trac/boost/wiki" >Guidelines >Maintenance Guidelines Best regards, Vicente

7 15

[Thread] Win32 exception handling
by David Abrahams 29 Nov '08

29 Nov '08

I talked to an organization a few days ago that wasn't using Boost.Thread because of the catch(...) clause in the thread launching functions. They wanted the usual Win32 termination behavior (where you get a stack backtrace) instead. While that might seem like a silly reason not to use Boost.Thread, it's legitimate. I told them about several ways to work around that issue, but I think all of them are more hassle and provide a less useful result (to them) than simply letting the exception leak. I wonder if the that would be a conforming implementation, whether a call to terminate() is required, and whether a preprocessor switch to allow exceptions to leak would be a good idea? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

14 46

[MultiIndex] Random Access mental model?
by David Abrahams 29 Nov '08

29 Nov '08

Hi, I'm trying to get a grip on what it means when I have a random access index in a multi_index_container. I have no mental model for what data structure you're actually creating, which makes it difficult to evaluate multi-index vs. hand-rolling my own container. If I was doing this myself, I'd use a combination of these two: hash_map<key, value> deque<hash_map<key, value>::pointer> because I need to maintain an LRU cache of what has been put in the map (i.e. I need O(1) push_back and pop_front). MultiIndex only lets me use sequenced<> which it implies essentially has the properties of list<hash_map<key, value>::iterator>... although I can imagine you could save a lot by using the same nodes for the hash_map and the list. Do you do that? Regardless, I could still save roughly one pointer per node with my deque. I'd think about trying to modify MultiIndex to let it do random access with deques, but I can't make head or tail of the implementation code used for random access. Could someone clarify what's going on in there? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

7 27

[math distributions] where to check for validity of distribution variables?
by Thijs van den Berg 29 Nov '08

29 Nov '08

I was playing around with implementing the (simple) Laplace distribution to get some feeling with "math/distributions" code and concepts. A lot of non-member functions for statistical distributions (like pdf, cdf) make a local copy of the distribution internal variables, and validate those local variables. An alternative would be to move the checking to member function of the distribution. instead of // CREATE LOCAL COPY OF DISTRIBUTION VARIABLES RealType sd = dist.standard_deviation(); RealType mean = dist.mean(); ... // VALIDATE THOSE LOCAL VARIABLES RealType result; if(false == detail::check_scale(function, sd, &result, Policy())) { return result; } if(false == detail::check_location(function, mean, &result, Policy())) { return result; } do it like this // VALIDATE DISTRIBUTION RealType result; if(false == dist.check()) { return result; } // CREATE LOCAL COPY OF VALID DISTRIBUTION VARIABLES RealType sd = dist.standard_deviation(); RealType mean = dist.mean(); I see two benefits: * the code is more compact this way and repeated code in most of the non member functions is centralized (into the distribution) * for multivariate distributions, the checking can be expensive (a covariance matrix of a multivariate normal needs to be semi positive definite). We could do the checking only once in the constructor & cache the result. What do you think? We might turn "having valid parameters" into a property of *all* distribution. As an alternative, we might add a non member function bool valid<distributionType... but that wouldn't allow for caching validation in e.g. a constructor In general (but in the scope of the constructs used in math/distributions & its non member functions): what are the arguments for placing code in either member or non-member functions ?

4 37

Bug with gcc and array
by Andreas Klein 29 Nov '08

29 Nov '08

Dear developers. I send this both to the boost and the gcc developers. I have found a strange limitation for the size of an array. The error is the same both for boost 1.36 and for the array in gcc 4.3.2 (and in the gcc 4.4 snapshot I use). I am almost sure that it is a bug of gcc and not of the array implementation. Here is the code. #include<array> using namespace std; int main () { array<unsigned int, (1<<22)> a; // Create a big array a[(1<<22)-13]=0; // This give a segmantation fault } In contrast a C-array works fine. int main () { unsigned int a[1<<22]; a[(1<<22)-13]=0; } Since the naturale implementation of the array class is just a wrapper around the C-style array this is very strange. I tryed to track down the bug. You use the following implementation: template<typename T, unsigned int n> class array { T C[n]; public: typedef unsigned int size_type; T& operator[](size_type p) { return C[p]; } }; If we change the C[n] to an explicite new it works fine. template<typename T, unsigned int n> class array { T* C; public: typedef unsigned int size_type; array() { C = new T[n]; } T& operator[](size_type p) { return C[p]; } }; It seams that this resolves the bug. But I can not explain why. I tested the code with the intel compiler and it works fine for both implementations. So it seams that it is a gcc bug, that the first solution do not work. What happens here? Kind regards Andreas Klein

6 8

Is Boost.Range broken?
by Tomas Puverle 28 Nov '08

28 Nov '08

I decided to split off this part of another thread to try to get a consensus on the changes that occurred in Boost.Range with boost 1.35. The background is discussed elsewhere. What I'd like to do here is to come to an agreement with Thorsten and other developers on the following issues: 1) Is the change in the behaviour of Boost.Range in fact a defect? 2) What should be done about it? Here are the reasons why I think Boost.Range is broken: 1) Empty ranges are useless and they cannot even be reliably tested for emptiness. The empty() function now asserts and the is_singular() function behaves differently between debug and release builds, making it impossible to detect if a range is, in fact, empty. In addition, this is not documented well and can lead to subtle bugs and undefined behaviour, which will only manifest itself in release builds. 2) The behaviour is unintuitive. Range is a generalisation of the interface of the std::containers. With this change, containers and ranges can no longer be used in the same code path. 3) Reintroducing the "singular" member into release builds to make the is_singular() function work correctly will defeat the purpose of the size optimisation, while still not achieving interface compatibility with std::containers. 4) Having the additional if() condition in size() and empty()is unlikely to be a large burden on most programs. I would expect most programs will spend more time iterating data than testing ranges for emptiness. 5) The change could be reverted without affecting users. For those who are relying on the new behaviour, the change to empty() and size() should be immaterial, as they cannot be calling them now on singular ranges anyway. My proposed fix would be the following: Roll back iterator_range to the pre-1.35 release state immediately. For a future release, create a new class, boost::simple_range which has the behaviour of the new version (i.e. no singular member). Publicly derive iterator_range from simple_range and provide additional factory functions such as make_simple_range(). I would appreciate any feedback on this issue. Kind regards, Tom

16 106

Review Wizard Report for November 2008
by Ronald Garcia 28 Nov '08

28 Nov '08

============================================== Review Wizard Status Report for November 2008 ============================================== News ==== May 7 - Scope Exit Library Accepted - Awaiting SVN May 17 - Egg Library Rejected August 14 - Boost 1.36 Released New Libraries: Accumulators, Exception, Units, Unordered Containers August 27 - Finite State Machines Rejected September 10 - Data Flow Signals Rejected September 30 - Phoenix Accepted Conditionally November 3 - Boost 1.37 Released New Library: Proto November 10 - Thread-Safe Signals Accepted - Awaiting SVN November 25 - Globally Unique Identifier Library mini-Review in progress Older Issues ============ The Quantitative Units library, accepted in April 2007 is in SVN (listed as units). The Time Series Library, accepted in August 2007, has not yet been submitted to SVN. The Switch Library, accepted provisionally in January 2008, has not yet been submitted for mini-review and full acceptance. Property Map (Fast-Track) and Graph (Fast-Track) have been removed from the review queue. The author (Andrew Sutton) intends to submit a new version of this work at a later time. A few libraries have been reviewed and accepted into boost, but have not yet appeared in SVN as far as I can tell. Could some light be shed on the status of the following libraries? Apologies if I have simply overlooked any of them: * Flyweight (Joaquin Ma Lopez Munoz) * Floating Point Utilities (Johan Rade) * Factory (Tobias Schwinger) * Forward (Tobias Schwinger) * Scope Exit (Alexander Nasonov) * Time Series (Eric Niebler) * Property Tree (Marcin Kalicinski) -- No documentation in SVN Any information on the whereabouts of these libraries would be greatly appreciated. For libraries that are still waiting to get into SVN, please get them ready and into the repository. The developers did some great work making the libraries, so don't miss the chance to share that work with others. Also notice that the review process page has been updated with a section on rights and responsibilities of library submitters. General Announcements ===================== As always, we need experienced review managers. The review queue has been growing substantially but we have had few volunteers, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants or library contributors. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "garcia at osl dot iu dot edu" and "phillips at mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. A recent effort is trying to secure at least five people who promise to submit reviews as a precondition to starting the review period. Consider volunteering for this and even taking the time to create the review as early as possible. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. If you're a library author and plan on submitting a library for review in the next 3-6 months, send Ron or John a short description of your library and we'll add it to the Libraries Under Construction below. We know that there are many libraries that are near completion, but we have hard time keeping track all of them. Please keep us informed about your progress. Review Queue ============ * Lexer * Boost.Range (Update) * Shifted Pointer * Logging * Futures - Williams * Futures - Gaskill * Join * Pimpl * Constrained Value * Thread Pool * Polynomial -------------------- Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Sandbox Vault <http://boost-consulting.com/vault/ index.php? action=downloadfile&filename=boost.lexer.zip&directory=Strings%20-% 20Text%20Processing&>`__ :Description: A programmable lexical analyser generator inspired by 'flex'. Like flex, it is programmed by the use of regular expressions and outputs a state machine as a number of DFAs utilising equivalence classes for compression. Boost.Range (Update) -------------------- :Author: Neil Groves :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=range_ex.zip&directory=>`__ :Description: A significant update of the range library, including range adapters. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?&direction=0&order=&directory=Memory>`__ :Description: Smart pointers are in general optimized for a specific resource (memory usage, CPU cycles, user friendliness, ...) depending on what the user need to make the most of. The purpose of this smart pointer is mainly to allocate the reference counter (or owner) and the object itself at the same time so that dynamic memory management is simplified thus accelerated and cheaper on the memory map. Logging ------- :Author: John Torjo :Review Manager: Gennadiy Rozental :Download: http://torjo.com/log2/ :Description: Used properly, logging is a very powerful tool. Besides aiding debugging/testing, it can also show you how your application is used. The Boost Logging Library allows just for that, supporting a lot of scenarios, ranging from very simple (dumping all to one destination), to very complex (multiple logs, some enabled/some not, levels, etc). It features a very simple and flexible interface, efficient filtering of messages, thread-safety, formatters and destinations, easy manipulation of logs, finding the best logger/filter classes based on your application's needs, you can define your own macros and much more! Futures ------- :Author: Braddock Gaskill :Review Manager: Tom Brinkman :Download: http://braddock.com/~braddock/future/ :Description: Joint review of the Futures libraries scheduled for 1/5/09-1/20/09. The goal of the boost.future library is to provide a definitive future implementation with the best features of the numerous implementations, proposals, and academic papers floating around, in the hopes to avoid multiple incompatible future implementations in libraries of related concepts (coroutines, active objects, asio, etc). This library hopes to explore the combined implementation of the best future concepts. Futures ------- :Author: Anthony Williams :Review Manager: Tom Brinkman :Download: http://www.justsoftwaresolutions.co.uk/files/ n2561_future.hpp (code) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/ n2561.html (description) :Description: Joint review of the Futures libraries scheduled for 1/5/09-1/20/09. This paper proposes a kind of return buffer that takes a value (or an exception) in one (sub-)thread and provides the value in another (controlling) thread. This buffer provides essentially two interfaces: * an interface to assign a value as class promise and * an interface to wait for, query and retrieve the value (or exception) from the buffer as classes unique_future and shared_future. While a unique_future provides move semantics where the value (or exception) can be retrieved only once, the shared_future provides copy semantics where the value can be retrieved arbitrarily often. A typical procedure for working with promises and futures looks like: * control thread creates a promise, * control thread gets associated future from promise, * control thread starts sub-thread, * sub-thread calls actual function and assigns the return value to the promise, * control thread waits for future to become ready, * control thread retrieves value from future. Also proposed is a packaged_task that wraps one callable object and provides another one that can be started in its own thread and assigns the return value (or exception) to a return buffer that can be accessed through one of the future classes. With a packaged_task a typical procedure looks like: * control thread creates a packaged_task with a callable object, * control thread gets associated future from packaged_task, * control thread starts sub-thread, which invokes the packaged_task, * packaged_task calls the callable function and assigns the return value, * control thread waits for future to become ready, * control thread retrieves value from future. Notice that we are in the unusual position of having two very different libraries with the same goal in the queue at the same time. The Review Wizards would appreciate a discussion of the best way to hold these two reviews to produce the best possible addition to Boost. Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=Pimpl.zip&directory=&>`__ http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Constrained Value ----------------- :Author: Robert Kawulak :Review Manager: Jeff Garland :Download: http://rk.go.pl/f/constrained_value.zip :Description: Review scheduled for 12/1/08-12/10/08 The Boost Constrained Value library contains class templates useful for creating constrained objects. A simple example is an object representing an hour of a day, for which only integers from the range [0, 23] are valid values: :: bounded_int<int, 0, 23>::type hour; hour = 20; // OK hour = 26; // exception! Behavior in case of assignment of an invalid value can be customized. For instance, instead of throwing an exception as in the example above, the value may be adjusted to meet the constraint: :: wrapping_int<int, 0, 255>::type buffer_index; buffer_index = 257; // OK: wraps the value to fit in the range assert( buffer_index == 1 ); The library doesn't focus only on bounded objects as in the examples above -- virtually any constraint can be imposed by using a predicate: :: // constraint (a predicate) struct is_odd { bool operator () (int i) const { return (i % 2) != 0; } }; :: // and the usage is as simple as: constrained<int, is_odd> odd_int = 1; odd_int += 2; // OK ++odd_int; // exception! The library has a policy-based design to allow for flexibility in defining constraints and behavior in case of assignment of invalid values. Policies may be configured at compile-time for maximum efficiency or may be changeable at runtime if such dynamic functionality is needed. Thread Pool ----------- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boostpro.com/vault/ index.php?action=downloadfile&filename=boost-threadpool. 2.tar.gz&directory=Concurrent%20Programming>`__ :Description: The library provides: - thread creation policies: determines the managemnt of worker threads - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time - channel policies: manages access to queued tasks - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited numer of queued tasks - rendezvous syncron hand-over between producer and consumer threads - queueing policy: determines how tasks will be removed from channel - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one) - tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). - returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> ``this_thread::interruption_point()`` ). Polynomial ---------- :Author: Pawel Kieliszczyk :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boostpro.com/vault/ index.php? action=downloadfile&filename=polynomial.zip&directory=>`__ :Description: The library was written to enable fast and faithful polynomial manupulation. It provides: - main arithmetic operators (+, -, * using FFT, /, %), - gcd, - different methods of evaluation (Horner Scheme, Compensated Horner Algorithm, by preconditioning), - derivatives and integrals, - interpolation, - conversions between various polynomial forms (special functions for creating Chebyshev, Hermite, Laguerre and Legendre form). Libraries under development =========================== Please let us know of any libraries you are currently developing that you intend to submit for review.

7 8

Is the bellman_ford_shortest_paths function missing an overload with the root vertex?
by Geoff Hilton 28 Nov '08

28 Nov '08

Quick question, was the fact that there is no bellman_ford_shortest_paths overload in the BGL that allows for the specification of the root vertex intentional? I'm using MSVC9 and tried using the named parameters overload but it won't compile. Ditto for dijkstra_shortest_paths and dag_shortest_paths actually. Here's what I have that won't compile with (twice) the error message: error C2248: 'Weight<long long>::Weight': cannot access private member declared in class 'Weight<long long>' c:\program files\boost\boost_1_37_0\boost\graph\bellman_ford_shortest_paths.hpp 155 class ShortestPathBellmanFordForward: public ShortestPathFunction { public: virtual ~ShortestPathBellmanFordForward(){} virtual AlgoResult operator()( const vertex_descriptor startingVertex, const WeightComparer<long long>& comparer, Graph& graph) const { const size_t numVertices = boost::num_vertices(graph); AlgoResult retval; retval.first = PredecessorMap(numVertices); retval.second = DistanceMap(numVertices); vertex_index_prop_t vindex = get(boost::vertex_index, graph); boost::bellman_ford_shortest_paths(graph, numVertices, weight_map(boost::get(&EdgeProp::weights, graph)). predecessor_map(boost::make_iterator_property_map( retval.first.begin(), vindex)). distance_map(boost::make_iterator_property_map( retval.second.begin(), vindex)). root_vertex(startingVertex). distance_combine(WeightCombiner<long long>()). distance_compare(comparer)); return retval; } }; Thanks, Geoff

1 2

Mingw testing
by Vladimir Prus 28 Nov '08

28 Nov '08

There seem to be no trunk tests running for gcc on windows (mingw). Did I miss something? Assuming I'm not, it would be really great to see mingw tested, as this is becoming a commonly used thing these days. Is anybody willing to do mingw testing? Thanks, Volodya

2 1

Re: [boost] [Review] UUID library (mini-)review starts today, November 23rd
by Vladimir.Batov＠wrsa.com.au 28 Nov '08

28 Nov '08

*** What is your evaluation of the design? Unfortunately I have serious reservations about the interface. Like, 1. "uuids" namespace seems unnecessary and burdensome. The generator classes can be introduced inside boost::uuid. 2. handling "char const*", "wchar_t const*", std::basic_string-based arguments should be templated/generalized. 3. Using a separate "generator" class to create a new UUID seems unorthodox as I feel the standard way of calling a constructor would be more inline with the standard C++ practices. Like boost::uuids::basic_uuid_generator<boost::mt19937> gen2; boost::uuid id(gen2); instead of boost::uuids::basic_uuid_generator<boost::mt19937> gen2; boost::uuids::uuid u2 = gen2(); That way boost::uuid id; // Works as Linux uuid_generate(); boost::uuid id(gen2); // Works as Linux uuid_generate_random(); 4. The default uuid() creating a "null" UUID is too subtle, wide open for misinterpretation and in fact counter-intuitive. For example, my (and many others that I know) interpretation of that constructor is like Linux uuid_generate() was called behind it. The creation of an invalid/null UUID needs to be explicitly stated with something like boost::uuid id = boost::uuid::null(); boost::uuid id = boost::uuid::invalid(); then "is_null()" method would be somewhat expected/justified. 5. I'd expect to be able to use "if (!uuid) then..." rather than "if (uuid.is_null()) then...". 6. to_wstring() does not seem to belong to the class. I understand it is conveniend but I fdo not feel that is core UUID functionality and, therefore, should (and can) be handled by other means. *** What is your evaluation of the implementation? I am OK with the implementation with a few comments. 1. Unfortunately, it does not seem to provide time-based construction. I read explanations why not but the usefulness of such a simple concept very much depends on its completeness. 2. I was surprised to see NULL used and postincrements. 3. A lot of raw numbers around the code. 4. I am very suspicious of using std::streams as from what I know they are not exactly fast. *** What is your evaluation of the documentation? Well, in all honesty I do not feel like the uuid.html file supplied with the package (uuid_v13.zip) can be considered as adequate documentation. Explanations seem scetchy. Links seem broken (like "see operators.hpp" points to a non-existing "operators.htm"). *** What is your evaluation of the potential usefulness of the library? I certainly think such a facility needed. *** Did you try to use the library? With what compiler? Did you have any problems? Tried with MSVC8 with results similar to already reported. Iseems like at least some of the warnings (like "warning C4244: '=' : conversion from 'int' to 'char', possible loss of data") need to be addressed. *** How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a couple of hours with it. *** Are you knowledgeable about the problem domain? Well, I consider myself a "knowledgeable user". I certainly will not be able to claim to be intimately familiar with the generation algorithms. *** Conclusion: The UUID concept is most certainly very useful and such a facility is an essential gadget in everyone's toolbox. However, there are many implementations around (OpenLDAP, Linux, Windows to name a few). For boost::uuid to be accepted and used instead other alternatives it needs to be as complete as its competitors and to stand out -- to be superior in interface, convenience or something. In a couple of hours I spent with boost::uuid I unfortunately did not manage to get that impression. Therefore, I am reluctantly voting against its acceptance in its present form. Thanks, Vladimir.

2 1

Making a new contribution - weak_hash_map
by Yoni Lavi 28 Nov '08

28 Nov '08

I'd like to contribute a C++ class template that implements something similar to java.util.WeakHashMap; it uses boost::intrusive::iunordered_set and boost::pool::fast_pool_allocator internally. This is the first time I'm looking to get into boost development in general. I'm not aware of any trivial way to implement this using existing components of the boost library, but I could have easily overlooked something so let me know if I am mistaken. I'd also like to know if there's any interest in such a contribution at all - anyone else thinks this class could be useful? Briefly, given a key space and value space, the class provides a way to lookup (and optionally create) values by a unique key, in a thread safe manner. A smart pointer to the entry (<key, value> pair) is returned from the lookup/create function. The tricky part is to make such entries automatically destroy themselves when no longer in use. The set itself cannot store a shared_ptr or the use count would never reach zero; it has to rely on weak_ptr and try to lock() it. There is also a race condition that needs to be taken care of (lock() may fail if refcount just dropped to zero in another thread). Lastly, it also has to handle the case where the weak_hash_map is destroyed but its entries persist, and again this needs to be properly synchronized. The implementation makes use of insert_check and insert_commit to implement a "create-or-get" function as well. I have also written an intrusive smart pointer type and that made it possible to use raw pointers instead of the weak_ptr's in the implementation. It's not that this stuff is rocket science as much as it involves lots of boilerplate code (e.g. making an entry hasher out of a key hasher, key/entry and entry/entry equality from key/key equality, resizing the hash table automatically, synchronization, allocation... the class I've written takes care of a lot of the ugly details. If anyone's interested, please fill me in on the process of making such a contribution? Thanks.

1 0

[utility/swap] boost::swap release update
by Niels Dekker - mail address until 2010-10-10 27 Nov '08

27 Nov '08

As far as I'm concerned, the boost::swap utility is now ready to be used within other Boost libraries, at the release branch. Joseph Gauterin has merged the utility from the trunk to the release branch two weeks ago, and its release regression page is now entirely green: http://www.boost.org/development/tests/release/developer/utility-swap_.html Just to remind you: The boost::swap utility makes it easier to swap two objects of the same type in a generic and efficient way, because it tries to find the most appropriate swap overload by argument-dependent lookup (ADL), whenever applicable. Thereby it works around the issues some compilers appear to have regarding ADL. The boost::swap utility also supports swapping built-in arrays. The utility was developed with help from David Abrahams and Steven Watanabe. See also: http://svn.boost.org/svn/boost/branches/release/libs/utility/swap.html http://svn.boost.org/svn/boost/branches/release/boost/utility/swap.hpp BTW, I've just added a boost::swap overload to the release version of Fernando Cacciola's value_initialized (utility/value_init.hpp), which is actually implemented by calling the boost::swap utility: https://svn.boost.org/trac/boost/changeset/49967 According to the following ticket: https://svn.boost.org/trac/boost/ticket/2243 Unswappably yours, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

Boost.Future & review of C++0x accepted libraries implementations
by vicente.botet 27 Nov '08

27 Nov '08

Hi, The Anthony Future + Packaged task proposals have been adopted by the C++ Standard. Is there a sense to review both Futures libraries together? Can we accept the Braddock library if it not conforms to the standard? As the interface and the design rationale for libraries already adopted by the C++ Standard such Chrono seem to be out of the scope of a review, which is the contents expected for such libraries to be adopted? Do we need a different review process? BTW, the threadpool library uses Braddock Future library. Thanks, Vicente

5 14