- Boost - lists.boost.org

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