April 2010 - Boost - lists.preview.boost.org

[GSoC] Bonding period
by Andrew Sutton 04 May '10

04 May '10

Hi All, If your proposal was accepted for GSoC 2010, then you will need to read this email thoroughly since it outlines the basic instructions for getting started with Boost development and your Summer Work. There are a couple of things you'll have to do (detailed instructions follow). 1. Introduce yourself to your mentor 2. Request SVN sandbox access from the Boost owners 3. Get started with Boost 4. Read about bjam and Quickbook 5. Write Code = Detailed instructions = == Introducing Yourself == Send an email to your mentor from the account that you want to receive Boost GSoC-related communications from. We're collecting your contact information in case we need to get in touch. If you have other secondary email address', please forward those also. There may be some organizational overhead to interacting with your mentor. We are still determining the best way to manage some aspects of this process. == Requesting SVN Access == Email the boost owner mailing list and request SVN *sandbox* write access for your GSoC project. Be sure to state that you are a student working on a GSoC 2010 project. Detailed instructions are given here [1] under "Getting a Trac SVN Userid". Your work will ultimately be hosted in this URL [2]. * Note to owners: if you want to validate students you can email me or I can grant you access to the GSoC webapp. == Getting Started == Read this [3] carefully, and follow the instructions. If you want to build Boost's trunk, follow the instructions here [4]. == Bjam and Quickbook == Bjam is the build tool used to compile Boost libraries, test suites, examples, and applications. For information on writing Bjam project files, read the manual, here [5]. Quickbook is the preferred* tool used to document the Boost libraries. It is a frontend to the BoostBook XML schema, which is an extension of the DocBook schema. The documentation toolchain is used to build online and PDF documentation for the Boost libraries. Documentation for writing Quickbook files can be found here [6]. * I could be wrong, but it is popular and also quite nice. == Writing Code == I would suggest trying to build (and document) some small example programs using the Boost development environment before diving in to your project. For example, port some of your programming assignments to Boost -- just don't commit them to the SVN repository :) This will help familiarize you with the Boost infrastructure. Also, read the Boost Guidelines and Requirements [7] before starting your project. These determine the layout of your directory structuring, how to name your files, and basic styles used throughout the Boost C++ Libraries. Additional information on techniques for generic programming can also be found here [8]. These techniques are used throughout many Boost libraries and are definitely worth reading about and understanding. I think that's about it for now. If I missed something, hopefully one of the other contributors will be able to point it out :) Welcome to Boost, and good luck on your summer projects! Andrew Sutton andrew.n.sutton(a)gmail.com [1] https://svn.boost.org/trac/boost/#GettingaTracSVNUserid [2] http://svn.boost.org/svn/boost/sandbox/SOC/2010/ [3] http://www.boost.org/doc/libs/1_42_0/more/getting_started/index.html [4] https://svn.boost.org/trac/boost/wiki/BoostSubversion [5] http://www.boost.org/doc/tools/build/doc/html/index.html [6] http://www.boost.org/doc/libs/1_42_0/doc/html/quickbook.html [7] http://www.boost.org/development/requirements.html [8] http://www.boost.org/community/generic_programming.html

7 16

Re: [boost] [repost][multiarray] Bug with boost::detail::multi_array::array_iterator on MSVC 2010RC?
by Thomas Klimpel 04 May '10

04 May '10

Jesse Perla wrote: > I have attached my test files. Any ideas or patches would be appreciated I could reproduce the problem with MSVC 2010beta2. I noticed that only the debug version fails to build. So I added the line #define _HAS_ITERATOR_DEBUGGING 0 and everything compiled fine. So the simplest solution is to add ADD_DEFINITIONS(-D_HAS_ITERATOR_DEBUGGING=0) to your CMakeLists.txt, which many people recommend in any case, because they claim that the debug version under MSVC would otherwise violate the "runtime complexity specifications" of the corresponding containers and iterators. (I don't know whether this is really true, but I really think that this workaround is not unreasonable.) But of course, you want to know whether this is a bug in boost::multi_array or a bug in MSVC 2010beta2. Before we come to that, another "workaround" would be to change multi_array/iterator.hpp:56 for , boost::random_access_traversal_tag to , std::random_access_iterator_tag This will most probably work, but would lying to the standard library, because the reference reference type of the corresponding iterator is not value_type& (but a proxy): http://lists.boost.org/boost-users/2006/11/23565.php What effectively happens it that the iterator gets the category "input_iterator", but std::copy wants to have an "output_iterator". I think I understand why the iterator doesn't satisfies the requirement of a "forward_iterator", but it's unclear to me why it didn't qualify as an "output_iterator". There is an "input_output_iterator_tag" in "boost/iterator/detail/facade_iterator_category.hpp", so it would have been possible for the iterator to be both "input_iterator" and "output_iterator". However, it seems to me that "input_output_iterator_tag" is never used in the Boost.Iterator library. I would have to read more about "output_iterator" to understand whether Boost.Iterator is correct here. With my current understanding of "output_iterator", I would say it's a bug in "boost/iterator/detail/facade_iterator_category.hpp". Perhaps somebody with more knowledge about "output_iterator" and Boost.Iterator can explain to me why an iterator using the "boost::random_access_traversal_tag" for the "CategoryOrTraversal" template parameter of "iterator_facade" will never get the category "output_iterator" (or "input_output_iterator_tag"). Regards, Thomas

4 6

DotNet FileSystemWatcher like library proposal.
by Fernando Pelliccioni 03 May '10

03 May '10

Hello all, I am working on a library like DotNet FileSystemWatcher ( http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher%28VS.80…) Basically the library monitors for file system changes and notifies throwing events. First, it will support the following platforms: - Windows NT 5.0 (Windows 2000) or higher using O/I Completion Port. - Linux 2.6.13 or higher using inotify. - FreeBSD 4.1 or higher using kqueue. - NetBSD 2.0 or higher using kqueue. - OpenBSD 3.6 higher using kqueue. (Not sure which version supports it) - MacOS/X 10.4 higher using kqueue. (Not sure which version supports it) Future supported platforms: - Linux from 2.4.0-test9 2.6.12 using dnotify. - Sun OpenSolaris using FEM API. Testing: I am testing the library on FreeBSD 7.2, Linux 2.6.31, Windows XP (Windows NT 5.1). I need help to test on older versions of these operating systems. Also in NetBSD, OpenBSD and mainly on MacOSX because I do not have the necessary hardware. I would like to include this library in Boost, I think would be useful. What do you think? If so, I would like to have a mentor (like GSoC) and experienced in Boost development. Thanks and regards, Fernando Pelliccioni --- References: - O/I Completion Port: http://msdn.microsoft.com/en-us/library/aa365198%28VS.85%29.aspx http://en.wikipedia.org/wiki/Input/output_completion_port - inotify: http://en.wikipedia.org/wiki/Inotify - kqueue: http://people.freebsd.org/~jlemon/papers/kqueue.pdf http://en.wikipedia.org/wiki/Kqueue - dnotify: http://en.wikipedia.org/wiki/Dnotify

6 8

Re: [boost] [castor] Interest in Logic Paradigm for C++ ?
by Joris IJsselmuiden 02 May '10

02 May '10

My humble opinion to the matter: I think it is a great idea to try and make Castor part of Boost. I have been using Castor in my research for a while now, and I think that it is definitely Boost-material. A logic engine can be a powerful tool, and it is a shame that C++ doesn't have one readily available. I am confident that Castor is the best choice for adding logic support to Boost. As far as I know, Boost is the most popular code-base that is not part of the C++ standard library yet. So, making Castor part of Boost would be a great way of increasing Castor's visibility. It would be nice to keep Castor available as a stand-alone library, so that you don't need Boost if you only want to use Castor. But I am sure that this issue can be solved: Castor could be a Boost "companion" library, or one could have a stand-alone version and a Boost version side-by-side. Although this last solution doesn't seem that great to me. I hope I will find the time to do some testing for Castor 1.1. Keep in touch! Joris Ijsselmuiden _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969

3 3

Parallel Boost Algorithm
by anil khadka 02 May '10

02 May '10

I am pretty new to both boost and parallel boost. I am using Brandes Centrality algorithm, but the performance really doesn't meet my expectation. If I used Java, which is only using 1 CPU core would complete it in around 30 hrs. The parallel version which use 8 CPU cores tooks 17 hours!! I don't know why there is just around 13 hours gain if i use 8 cores against 1, unless there are lots and lots of communication between each cores. I am using just 1 machine (not a cluster), right now. Graph size is Node 80K, edges 120K I am reading edges from files. I used distributed compressed_sparse_row to represent graph. Right now, it seems like all the cpu cores are reading files on its own, I am assuming each CPU core will takes its graph part automatically (distributed algorithm do it ?). Note: I downloaded the parallel version from: http://osl.iu.edu/research/pbgl/software/ Any help/suggestions would be really appreciated. Metanil.

2 1

[contract] next round of development
by Lorenzo Caminiti 01 May '10

01 May '10

Hello all, FYI, I am starting the next round of development of Boost.Contract. Most of the planned modifications derive from feedback I have received from this mailing list -- thanks! My goal is to request Boost.Contract formal review after this round of development and related documentation updates. You can check the planned development items at: http://sourceforge.net/tracker/?group_id=253844&atid=1330818 Comments are always welcome. Regards, -- Lorenzo

2 2

Re: [boost] [contract] member initializers (was "diff n1962")
by Lorenzo Caminiti 30 Apr '10

30 Apr '10

On Sun, Apr 11, 2010 at 10:58 AM, vicente.botet <vicente.botet(a)wanadoo.fr> wrote: > I supose that the constructor preconditions are evaluated before the member initialization as this initialization can rely on the preconditions been satisfied. Note also that preconditions/postconditions must to be in the declaration part, and the member initialization is on the definition part. > > I understand that it is not easy for Boost.Contract to check the precondition before member initialization . To be able to do that you will need to have a first member or inherit from a 'precondition' class that do this precondition check, > > class C : C_constructor_precondition ... { > > C(T1 p1) : C_constructor_precondition(p1), ... { > // ... > } > }; > > but this seems to me a severe constraint and adds more complexity. I think that I can live with preconditions check after member initialization. Yes, "pre > base-init > member-init" will require to mess with the inheritance tree and I do not see how that can be done by the CONTRACT_CONSTRUCTOR() macro which is used at the constructor declaration level (so inside the class and after its inheritance declarations). However, special member variables could be used to implement "base-init > pre > member-init" (as indicated below). Do you think it is worth implementing "base-init > pre > member-init" instead of "base-init > member-init > pre"? For example: #define ASSERT(cond) if (!(cond)) throw std::runtime_error(# cond) struct y { y(int i) {} }; struct x: y { x(int i): y(i), x_i_pre_check_(i), num(i) {} struct x_i_pre_ { x_i_pre_() {} // Assert nothing (implicitly used by other constructors). x_i_pre_(const int& i) { ASSERT( i >= 123 ); } } x_i_pre_check_; x(double d): y(d), x_d_pre_check_(d), num(d) {} struct x_d_pre_ { x_d_pre_() {} x_d_pre_(const double& d) { ASSERT( d >= 1.23 ); } } x_d_pre_check_; int num; }; I think I can program the CONTRACT_CONSTRUCTOR() macro to do this. However, limitations are: 1) All member variables must be declared after the constructors. In this case num is declared at the bottom of the class. 2) Preconditions are NOT checked before base class construction but only after member variable construction. This might be OK because base classes will in turn implement their own preconditions if needed. However, I still think that "pre > base-init > member-init" is ideal over the "base-init > pre > member-init" implemented by this approach. That is because the derived class might have more stringent preconditions than the base classes, preconditions which could be checked to fail even before the base classes are constructed. 3) The macro syntax now needs to separate bases from members in the initializer list (this separation is not done by usual C++ syntax). This could be done using the following macro syntax: CONTRACT_CONSTRUCTOR( (x)( (double)(d) ) (y(d)) // Base class init (before pre). (precondition)( (i >= 123) ) (num(i)) // Member init (after pre). (postcondition)( (num == i) ) ({}) ) or: CONTRACT_CONSTRUCTOR( (x)( (double)(d) ) (y(d)) (members) (num(i)) // Note (members). (precondition)( (i >= 123) ) (postcondition)( (num == i) ) ({}) ) but a more natural C++-like syntax would be: CONTRACT_CONSTRUCTOR( (x)( (double)(d) ) (y(d)) (num(i)) (precondition)( (i >= 123) ) (postcondition)( (num == i) ) ({}) ) and this syntax cannot be used because I will not know how to inject the precondition check after y(d) but before num(i).

2 3

[contract] diff n1962
by Lorenzo Caminiti 30 Apr '10

30 Apr '10

Hello all, Below is a summary of the differences between Boost.Contract and the Contract Programming C++ standard proposal n1962. I know some of the authors of n1962, and also of its previous revisions, are on this mailing list -- I hope that they can provide comments at least. [n1962] Crowl and T. Ottosen, Proposal to add Contract Programming to C++ (revision 4), The C++ Standards Committee, 2006. All previous revisions of this proposal are also relevant (and related authors comments encouraged). Boost.Contract design was vastly based on n1962. However, in few places I deliberately made the different design decisions listed below. Based on your feedback, I would be happy to revisit my design decisions to align even more Boost.Contract with n1962. 1) SUBCONTRACTING n1962 allows only the base class to specify preconditions. Instead, Boost.Contract allows also derived classes to specify preconditions. Boost.Contract fully supports subcontracting as defined by substitution principles, implemented by Eiffel, and specified by prevision revisions of n1962 (n1613). However, Boost.Contract could be modified to comply with n1962. Why does n1962 allow preconditions only for the base classes? n1962 section 4.2.1: <<If the function F is virtual, we require that 1. only the base virtual function of F can have a precondition. Section 3.5 of n1613 explains how little redefinition of preconditions is used. Even though subcontracting is theoretically sound, it ends up being fairly useless in practice [3]. [3] A weaker precondition can be taken advantage of if we know the particular type of the object. If weaker preconditions should be allowed, then there exists two alternatives: to allow reuse of an existing contract or to require a complete redefinition. The former favours expressiveness, the latter favours overview.>>. 2) STATIC CLASS INVARIANTS n1962 does not support static class invariants. Instead, Boost.Contract supports static class invariants. Non-static class invariants are not checked at constructor entry, at destructor exit, and at entry/exit of static member functions (because there is no object in these cases). Static class invariants instead are always checked at entry/exit of constructors, destructor, and (static or non-static) member functions. I added static class invariants for completeness. Boost.Contract could drop static class invariants to comply with n1962 (but I find them useful). struct z { static int counter; int number; CONTRACT_CLASS( (z) (static) (invariant) ({ // Static class invariants (no object here). CONTRACT_ASSERT( counter >= 0 ); }) (invariant) ({ // Non-static class invariants (`this` present). CONTRACT_ASSERT( number <= counter ); }) ) ... }; Why does n1962 not support static class invariants? 3) ARBITRARY CODE IN CONTRACTS n1962 allows only a list of assertions, eventually guarded by if-statements, in invariants, preconditions, and postconditions. Instead, Boost.Contract allows for any C++ code in the contract. Boost.Contract documentation recommends to keep the contract code simple, limited to a list of assertions eventually guarded by if-statements (otherwise, it is more likely you have bugs in the contracts than in the actual code). However, I think it would be strange for a library to enforce such a constraint at compile-time -- I agree that language support for CP should instead enforce this constraint at compile-time. Boost.Contract could be modified to enforce this constraint by removing the CONTRACT_ASSERT() macros. Would this complicate the macro syntax even more? template<typename T> class myvector { CONTRACT_FUNCTION_DECL( (iterator) (erase)( (iterator)(first) (iterator)(last) ) (copyable) (postcondition) (result) ( // no `{` bracket ( size() == (CONTRACT_OLDOF(this)->size() - std::distance(first, last) ) ( if (empty()) (result == end()) ) // if-guarded condition ) // no `}` braket ... ) ... }; Note how the postconditions are just a preprocessor sequence of boolean expressions asserting the contract. The if-guarded conditions can AND (&&) multiple assertions plus they can list an optional 3rd element for the else block, for example: (precondition) ( (if (check) ( then1 && then2 ) else ( else1 && else 2 ) ) // endif ) If check is true then then1 and then2 conditions are asserted, else else1 and else2 conditions are asserted. 4) BODY KEYWORD n1962 does not use the body keyword. Instead, Boost.Contract macros use (body). Boost.Contract could be changed to remove the need for (body) -- the body will simply be the last element in the contract sequence. This way, and removing also the CONTRACT_ASSERT(), Boost.Contract syntax will be _exactly_ the same as n1962 with the "only" addition of the () preprocessor wrappings: template<typename T> // n1962 syntax class myvector { void push_back(const T& element) precondition { size() < max_size(); } postcondition { back() == element; size() == (oldof size() + 1); } { vector_.push_back(element); } ... }; template<typename T> // Boost.Contract syntax class myvector { CONTRACT_FUNCTION_DECL( (void) (push_back)( (const T&)(element) ) (copyable) (precondition) ( // no CONTRACT_ASSERT() ( size() < max_size() ) ) (postcondition) ( ( back() == element ) ( size() == (CONTRACT_OLDOF(this)->size() + 1) ) ) ({ // no (body) vector_.push_back(element); }) ) ... }; Is the macro syntax more readable with or without (body) and/or CONTRACT_ASSERT()? 5) CONTRACT CHECKING ORDER (policy) n1962 checks contracts as pre > inv > body > inv > post. Instead, Boost.Contract checks contracts as inv > pre > body > inv > post, where inv is static-inv > non-static-inv. Note that Boost.Contract checks class invariants before preconditions while n1962 does not. However, n1962 footnote [9] says ``Strictly speaking the invariant needs to hold before the precondition is executed because the contracts might call public functions of the class which require the invariant to be established. Currently we do not expect that to be a practical problem though, and the current specification is easier to implement.''. In addition, if invariants are checked first programmers can assert pre/postconditions assuming the class invariants are true (furthermore, non-static class invariants can be programmed assuming static class invariants are true). For example, if the class invariants were to assert a member pointer to be not null, both pre/postconditions can assert conditions on this pointer without checking for nullity first. Therefore, I concluded Boost.Contract inv > pre is a preferred approach over n1962 pre > inv. However, Boost.Contract could be changed to check preconditions before invariants to comply with n1962. 6) DISABLE ASSERTION CHECKING WITHIN ASSERTIONS CHECKING (policy) n1962 only disables assertion checking from within preconditions checking. Instead, Boost.Contract disables assertion checking from within all contract checking. I found this policy useful to prevent infinite recursion. Previous revisions of n1962 (n1613) specified the same policy implemented by Boost.Contract. Furthermore, Eiffel implements the Boost.Contract policy. Boost.Contract could be changed to comply with n1962. Why does n1962 disable assertion checking only from within preconditions? 7) NESTED FUNCTION CALLS (policy) n1962 disable nothing. Instead, Boost.Contract disables invariant checking within nested function calls. I found this policy useful to prevent infinite recursion. Previous revisions of n1962 (n1613) specified the Boost.Contract policy. Eiffel disables all checks (not just invariants). Boost.Contract could be changed to comply with n1962. Why does n1962 not disable invariants checking in nested calls? 8) CODE ORDERING Both n1962 and Boost.Contract require preconditions > postconditions > body to be specified in this order. Instead, Eiffel uses preconditions > body > postconditions. People new to CP usually ask why the order is not pre > body > post when looking at the contracts for the 1st time. However, after using the library, the same people appreciate pre > post > body more because the programming is cleaner "first program the contracts (pre and post) then the body". I think using only one ordering is better to enforce code consistency and I prefer pre > post > body over Eiffel's pre > body > post. Do you think Boost.Contract should be modified to support both n1962 and Eiffel orderings? 9) LOOP VARIANTS n1962 does not support loop variants. Instead, Boost.Contract supports loop variants with semantics similar to Eiffel's loop variants. I find loop variants not useful in practice so I do not think I would personally recommend them for language support. However, it was easy enough to add them to Boost.Contract and I would leave them in the library. 10) FAILURE HANDLERS In n1962 section 4.6: <<The precondition for all the set_XX_handler functions should be r != 0>>. Instead, Boost.Contract behaviour is undefined if a null handler function pointer `r` is specified. Boost.Contract mirrors the C++ specifications for std::set_terminate() which indicates undefined behaviour if a null terminate handler function pointer is specified. This could be changed. 11) OLDOF n1962 allows to apply oldof to *any expression* that can be copied. Instead, Boost.Contract only supports CONTRACT_OLDOF() for *object and the function parameters* that can be copied. This is a limitation of Boost.Contract because, for example, in order to get the old value of a vector size I need to copy the entire vector adding more overhead respect to copying just the vector size (which is simply an integer): oldof vector.size() // n1962: Just copy the integer size(). CONTRACT_OLDOF(vector).size() // Boost.Contract: Copy entire vector... Furthermore, if the vector object cannot be copied, I cannot not get its old size even if the size itself can be copied because it is just an integer: oldof noncopyable_vector.size() // n1962: OK, just copy the integer size(). CONTRACT_OLDOF(noncopyable_vector).size() // Boost.Contract: Cannot do this because cannot copy noncopyable_vector... Finally, the use of CONTRACT_OLDOF(variable) requires programmers to explicitly indicate that the variable type is copyable using (copyable) in the function signature adding syntactic overhead. Unfortunately, I do not know how to remove these library limitations. (All of that said, Boost.Contract old value support is very useful and it successfully covered all the uses cases and examples presented in n1962 and in a number of C++/Eiffel books/articles.) 12) CONSTANT-CORRECTNESS Block invariants are constant-correct in n1962 but not in Boost.Contract. (Class invariants and pre/postconditions are constant-correct in both n1962 and Boost.Contract.) Unfortunately, I do not know how to enforce constant-correctness of block invariants (and also of loop variants) for Boost.Contract because I cannot inject const within a code block: class z { void f() { const { // Can't do this... so f() is not const and block invariants are also not const in this context... ... // block invariant here } } }; This is a limitation of Boost.Contract. Regards, Lorenzo

5 19

Implementation of Factorization Library
by abhijith reddy 30 Apr '10

30 Apr '10

I am interested in implementing a module that will factor large numbers (10^25 -10^30) .. I think this can be added into the existing math and numerics library in boost. I'd be grateful if some could share their thoughts on this and comment on it. Thank you

3 2

[any] boost::get style accessors
by Christoph Heindl 30 Apr '10

30 Apr '10

Hi all, I couldn't find any boost::get<T> style accessors for boost::any, so I came up with an implementation that looks something along the following lines. #include <boost/any.hpp> #include <boost/call_traits.hpp> namespace boost { template<class T> typename boost::call_traits<T>::reference get(any &a) { return boost::any_cast<typename boost::call_traits<T>::reference>(a); } template<class T> typename boost::call_traits<T>::const_reference get(const any &a) { return boost::any_cast<typename boost::call_traits<T>::const_reference>(a); } } In case it cannot be converted to the desired destination type a bad_any_cast exception is thrown. The above code enables boost.any and boost.variant to be used interchangeably as far as boost::get<T> is concerned. Any thoughts? Best regards, Christoph

4 19

[1.43][statechart] Permission to merge changeset 61637 to the release branch
by Andreas Huber 30 Apr '10

30 Apr '10

Hi I'd like to merge the following trivial fixes to the release branch: <https://svn.boost.org/trac/boost/changeset/61637> The fixes were tested by >50% of the testers without incident. Ok to go ahead? Thanks, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 2

[Interprocess] Compile error with VC10
by cg 30 Apr '10

30 Apr '10

I am trying Interprocess with VS2010, and got some compile error, the error message is: 1>ClCompile: 1>boost/interprocess/detail/move.hpp(358): error C2440: 'return' : cannot convert from 'boost::interprocess::mapped_region' to 'boost::interprocess::mapped_region &&' 1> You cannot bind an lvalue to an rvalue reference Any quick fix for it?

4 11

[spirit] VC10 ICE when defining a Karma/Qi rule in a 0x lambda
by Lars Viklund 29 Apr '10

29 Apr '10

Hi list, I encountered a rather amusing/horrible compiler error today when trying to wrap my head around the new Spirit. Apparently, VC++10 experiences a fatal internal compiler error when defining a Karma or Qi rule inside a lambda expression, as shown in the attached source at the bottom of this mail (and in the bug report). I reported a spirit bug [1] and a kind soul on the #boost channel linked me a similar Microsoft Connect bug [2], which seems to have sadly been ignored. I've got no idea in what edge of Spirit to start investigating this, as there's deep magic going on inside it, and would appreciate advice on what might be at fault, and whether there are any knobs I can twiddle. Could it be related to the recent thread on incomplete decltypes and odd rvalue references that VC10 has? [1] https://svn.boost.org/trac/boost/ticket/4160 [2] http://connect.microsoft.com/VisualStudio/feedback/details/541534/internal-… //---8<--- #include <boost/spirit/include/karma.hpp> int main() { []() { boost::spirit::karma::rule<char*> r; }; } //---8<--- -- Lars Viklund | zao(a)acc.umu.se

5 7

VC10 config - some regressions in several libraries
by John Maddock 29 Apr '10

29 Apr '10

Just a note that the recent changes to the VC10 config has produced several regressions in a number of libraries - I think these are all related to the use the rvalue references and move semantics. At present I can't say whether these are caused by bugs in VC10 rendering it's rvalue refs unusable (in which case we need a better test case in Boost.Config), or whether our library code isn't mature/portable enough yet given that this is a new and relatively untried feature. Can library authors making use of this feature investigate so we can decide what should be done here? Thanks! John.

13 27

[range][1.43] is boost::get or boost::at missing?
by vicente.botet 29 Apr '10

29 Apr '10

Hi, I'm wondering if a checked element access via at() is missing for Random Access ranges. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 2

[uuid] Confusing uuid_class example in documentation
by Sylvester-Bradley, Gareth 29 Apr '10

29 Apr '10

http://beta.boost.org/doc/libs/1_42_0/libs/uuid/uuid.html#POD%20Efficien cies includes some example code for making a uuid_class from the struct uuid POD. I was confused to see the example uuid_class both derives from boost::uuids::uuid *and* provides operator boost::uuids::uuid() [const]. Aren't the conversion operators unnecessary, as a conversion function is never called to convert an object to a base class of that type (by 12.3.2 [class.conv.fct])? In fact the source file that the documentation references (e.g. at https://svn.boost.org/trac/boost/browser/tags/release/Boost_1_43_0_beta1 /libs/uuid/test/test_uuid_class.cpp) doesn't include the conversion operators. I think the documentation should be updated to match. Cheers, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 1

[function] function_template.hpp has ambiguous mem_fn calls on compilers with std::mem_fn (VC10); simple 2-line fix
by Conrad Poelman 29 Apr '10

29 Apr '10

*Summary*: It seems that function_template.hpp needs "boost::" in front of mem_fn in two spots so as not to be ambiguous with std::mem_fn on compilers that have std::mem_fn. (mem_fn appears in that file 4 times; two spots already use fully-qualified "boost::mem_fn".) I entered this at https://svn.boost.org/trac/boost/ticket/4073, but just wondered what the process is for having this fix committed to boost repository. **Example**: Here's a reproducible example that won't compile in Visual Studio 2010 (produces an "ambiguous call to overloaded function" error regarding mem_fn - could be boost::mem_fn or could be std::mem_fn) but that compiles fine in other compilers that don't have an std::mem_fn: #include<boost/function.hpp> #include<string> class PrimitiveBuilder { public: bool someFunction( std::string& token ); void registerSomeFunction() { mPrimitiveFunctor =&PrimitiveBuilder::someFunction; // ambiguity error is here } private: typedef boost::function<bool (PrimitiveBuilder*, std::string& token)> PrimitiveFunctor; PrimitiveFunctor mPrimitiveFunctor; }; The above code compiles and works fine in VS 2010 once "boost::" is added to mem_fn in function_template.hpp. I look forward to hearing your thoughts. Thanks! -- Conrad

1 0

running the regression tests with SunCC 5.9
by Frank Meerkötter 29 Apr '10

29 Apr '10

Hello, I am trying to run the regression tests for boost on a SunSparc machine with the SunCC 5.9. As i am trying to evaluate a certain version of boost i provide a local tarball. python run.py --runner meerkoetter --toolsets=sun --user= --local=../boost/boost_1_42_0.tar.bz2 The tests sits for a few minutes at this line. Before it fails. # Starting tests ("/home/meerkoef/boost_regression/tools_bjam/bin.solarissparc/bjam" "-sBOOST_BUILD_PATH=/home/meerkoef/boost_regression:/home/meerkoef/boost_regression/tools_bb" "-sBOOST_ROOT=/home/meerkoef/boost_regression/boost" "--boost=/home/meerkoef/boost_regression/boost" "--boost-build=/home/meerkoef/boost_regression/tools_bb" "--debug-configuration" -l300 sun -d2 preserve-test-targets=off --dump-tests "--build-dir=/home/meerkoef/boost_regression/results" >>"/home/meerkoef/boost_regression/results/bjam.log" 2>&1)... # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 60, in ? runner(root) File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 193, in __init__ self.main() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 551, in main getattr(self,action_m)() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 516, in command_regression self.command_test() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 317, in command_test self.command_test_boost_build() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 354, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/home/meerkoef/boost_regression/results/boost/bin.v2/libs/any/test/any_test.test' The last few lines in bjam.log show: [...] boost-test(RUN) "config/no_void_returns_pass" : "libs/config/test/no_void_returns_pass.cpp" boost-test(COMPILE_FAIL) "config/no_void_returns_fail" : "libs/config/test/no_void_returns_fail.cpp" boost-test(RUN) "config/no_wchar_t_pass" : "libs/config/test/no_wchar_t_pass.cpp" boost-test(COMPILE_FAIL) "config/no_wchar_t_fail" : "libs/config/test/no_wchar_t_fail.cpp" don't know how to make <e>sun ...found 1 target... ...can't find 1 target... Any ideas how i can fix this? btw. i noticed that the tools are build using the gcc and not the sun compiler. Is this correct? In the end i don't care what compiler is used to create the regression testing tools but still it makes me wonder if the tests are compiled with the right compiler? Here is the complete log: # Running regressions in /home/meerkoef/boost_regression... # Creating regression scripts at /home/meerkoef/boost_regression/tools_regression_src... # Dowloading regression scripts from http://svn.boost.org/svn/boost/trunk/tools/regression/src... # Getting Boost.Build v2... # Downloading "http://beta.boost.org/development/snapshot.php/trunk/tools/build/v2" to "/home/meerkoef/boost_regression"... # Looking for old unpacked archives... # Unpacking boost tarball ("/home/meerkoef/boost_regression/tools_bb.tar.bz2")... # Unpacked into directory "/home/meerkoef/boost_regression/boost-trunk-2010-04-26-09-02-11-EDT" # Deleting "tools_bb" directory... # Renaming "/home/meerkoef/boost_regression/boost-trunk-2010-04-26-09-02-11-EDT" into "tools_bb" # Getting Boost.Jam... # Downloading "http://beta.boost.org/development/snapshot.php/tags/tools/jam/Boost_Jam_3_1…" to "/home/meerkoef/boost_regression"... # Looking for old unpacked archives... # Unpacking boost tarball ("/home/meerkoef/boost_regression/tools_bjam.tar.bz2")... # Unpacked into directory "/home/meerkoef/boost_regression/boost-tags-2010-04-26-09-02-30-EDT" # Deleting "tools_bjam" directory... # Renaming "/home/meerkoef/boost_regression/boost-tags-2010-04-26-09-02-30-EDT" into "tools_bjam" # Getting regression tools an utilities... # Downloading "http://beta.boost.org/development/snapshot.php/trunk/tools/regression" to "/home/meerkoef/boost_regression"... # Looking for old unpacked archives... # Unpacking boost tarball ("/home/meerkoef/boost_regression/tools_regression.tar.bz2")... # Unpacked into directory "/home/meerkoef/boost_regression/boost-trunk-2010-04-26-09-02-51-EDT" # Deleting "tools_regression" directory... # Renaming "/home/meerkoef/boost_regression/boost-trunk-2010-04-26-09-02-51-EDT" into "tools_regression" # Getting boost-build.jam... # Using local file "../boost/boost_1_42_0.tar.bz2" # Tag: "boost_1_42_0" # Looking for old unpacked archives... # Unpacking boost tarball ("../boost/boost_1_42_0.tar.bz2")... # Unpacked into directory "/home/meerkoef/boost_regression/boost_1_42_0" # Deleting "/home/meerkoef/boost_regression/boost" directory... # Renaming "/home/meerkoef/boost_regression/boost_1_42_0" into "/home/meerkoef/boost_regression/boost" # Preinstalled "/home/meerkoef/boost_regression/bjam" is not found; building one... # Found "bjam" source directory "/home/meerkoef/boost_regression/tools_bjam" # Building "bjam" (./build.sh )... ### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean ...found 1 target... ...updating 1 target... ...updated 1 target... ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= ...found 48 targets... ...updating 2 targets... [MKDIR] bin.solarissparc [COMPILE] bin.solarissparc/bjam ...updated 2 targets... # Searching for "bjam" in "/home/meerkoef/boost_regression/tools_bjam"... # bjam succesfully built in "/home/meerkoef/boost_regression/tools_bjam/bin.solarissparc/bjam" location # Preinstalled "/home/meerkoef/boost_regression/process_jam_log" is not found; building one... # Found "process_jam_log" source directory "/home/meerkoef/boost_regression/tools_regression/build" # Building "process_jam_log" ("/home/meerkoef/boost_regression/tools_bjam/bin.solarissparc/bjam" "-sBOOST_BUILD_PATH=/home/meerkoef/boost_regression:/home/meerkoef/boost_regression/tools_bb" "-sBOOST_ROOT=/home/meerkoef/boost_regression/boost" "--boost=/home/meerkoef/boost_regression/boost" "--boost-build=/home/meerkoef/boost_regression/tools_bb" "--debug-configuration" process_jam_log -d2 -l300)... notice: found boost-build.jam at /home/meerkoef/boost_regression/boost-build.jam notice: loading Boost.Build from /home/meerkoef/boost_regression/tools_bb notice: Searching /etc /home/meerkoef /home/meerkoef/boost_regression/tools_bb /home/meerkoef/boost_regression /home/meerkoef/boost_regression/tools_bb /home/meerkoef/boost_regression/tools_bb/kernel /home/meerkoef/boost_regression/tools_bb/util /home/meerkoef/boost_regression/tools_bb/build /home/meerkoef/boost_regression/tools_bb/tools /home/meerkoef/boost_regression/tools_bb/contrib /home/meerkoef/boost_regression/tools_bb/. for site-config configuration file site-config.jam . notice: Loading site-config configuration file site-config.jam from /home/meerkoef/boost_regression/tools_bb/site-config.jam . notice: Searching /home/meerkoef /home/meerkoef/boost_regression/tools_bb /home/meerkoef/boost_regression /home/meerkoef/boost_regression/tools_bb /home/meerkoef/boost_regression/tools_bb/kernel /home/meerkoef/boost_regression/tools_bb/util /home/meerkoef/boost_regression/tools_bb/build /home/meerkoef/boost_regression/tools_bb/tools /home/meerkoef/boost_regression/tools_bb/contrib /home/meerkoef/boost_regression/tools_bb/. for user-config configuration file user-config.jam . notice: Loading user-config configuration file user-config.jam from /home/meerkoef/boost_regression/tools_bb/user-config.jam . notice: iostreams: using prebuilt zlib notice: iostreams: using prebuilt bzip2 notice: [python-cfg] Configuring python... notice: [python-cfg] Checking interpreter command "python"... notice: [python-cfg] running command '"python" -c "from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))" 2>&1' notice: [python-cfg] ...requested configuration matched! notice: [python-cfg] Details of this Python configuration: notice: [python-cfg] interpreter command: "python" notice: [python-cfg] include path: "/usr/include/python2.4" notice: [python-cfg] library path: "/usr/lib/python2.4/config" "/usr/lib" warning: No toolsets are configured. warning: Configuring default toolset "gcc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html notice: will use 'g++' for gcc, condition <toolset>gcc-3.4.3 notice: using gcc libraries :: <toolset>gcc-3.4.3 :: /usr/sfw/bin /usr/sfw/lib /usr/sfw/lib32 /usr/sfw/lib64 notice: using gcc archiver :: <toolset>gcc-3.4.3 :: /usr/sfw/sparc-sun-solaris2.10/bin/ar notice: using gcc ranlib :: <toolset>gcc-3.4.3 :: /usr/sfw/sparc-sun-solaris2.10/bin/ranlib warning: toolset gcc initialization: can not find tool windres warning: initialized from notice: using rc compiler :: <toolset>gcc-3.4.3 :: as ...patience... ...found 487 targets... ...updating 27 targets... common.mkdir bin mkdir -p "bin" common.mkdir bin/gcc-3.4.3 mkdir -p "bin/gcc-3.4.3" common.mkdir bin/gcc-3.4.3/release mkdir -p "bin/gcc-3.4.3/release" gcc.compile.c++ bin/gcc-3.4.3/release/process_jam_log.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -D_CRT_SECURE_NO_WARNINGS -I"/home/meerkoef/boost_regression/boost" -c -o "bin/gcc-3.4.3/release/process_jam_log.o" "../src/process_jam_log.cpp" ../src/process_jam_log.cpp: In function `int main(int, char**)': ../src/process_jam_log.cpp:692: warning: comparison between signed and unsigned integer expressions gcc.compile.c++ bin/gcc-3.4.3/release/tiny_xml.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -D_CRT_SECURE_NO_WARNINGS -I"/home/meerkoef/boost_regression/boost" -c -o "bin/gcc-3.4.3/release/tiny_xml.o" "../src/detail/tiny_xml.cpp" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2 mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3 mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static" gcc.compile.c++ /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/operations.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/home/meerkoef/boost_regression/boost" -c -o "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/operations.o" "/home/meerkoef/boost_regression/boost/libs/filesystem/src/operations.cpp" gcc.compile.c++ /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/path.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/home/meerkoef/boost_regression/boost" -c -o "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/path.o" "/home/meerkoef/boost_regression/boost/libs/filesystem/src/path.cpp" gcc.compile.c++ /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/portability.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/home/meerkoef/boost_regression/boost" -c -o "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/portability.o" "/home/meerkoef/boost_regression/boost/libs/filesystem/src/portability.cpp" gcc.compile.c++ /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/utf8_codecvt_facet.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_All_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/home/meerkoef/boost_regression/boost" -c -o "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/utf8_codecvt_facet.o" "/home/meerkoef/boost_regression/boost/libs/filesystem/src/utf8_codecvt_facet.cpp" RmTemps /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a(clean) rm -f "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a" gcc.archive /home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a "/usr/sfw/sparc-sun-solaris2.10/bin/ar" rc "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/operations.o" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/path.o" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/portability.o" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/utf8_codecvt_facet.o" "/usr/sfw/sparc-sun-solaris2.10/bin/ranlib" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/system mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/system" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3 mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release" common.mkdir /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static mkdir -p "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static" gcc.compile.c++ /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/error_code.o "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"/home/meerkoef/boost_regression/boost" -c -o "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/error_code.o" "/home/meerkoef/boost_regression/boost/libs/system/src/error_code.cpp" RmTemps /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a(clean) rm -f "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a" gcc.archive /home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a "/usr/sfw/sparc-sun-solaris2.10/bin/ar" rc "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a" "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/error_code.o" "/usr/sfw/sparc-sun-solaris2.10/bin/ranlib" "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a" gcc.link bin/gcc-3.4.3/release/process_jam_log "g++" -o "bin/gcc-3.4.3/release/process_jam_log" "bin/gcc-3.4.3/release/process_jam_log.o" "bin/gcc-3.4.3/release/tiny_xml.o" "/home/meerkoef/boost_regression/boost/bin.v2/libs/filesystem/build/gcc-3.4.3/release/link-static/libboost_filesystem.a" "/home/meerkoef/boost_regression/boost/bin.v2/libs/system/build/gcc-3.4.3/release/link-static/libboost_system.a" -mimpure-text ...updated 27 targets... # Searching for "process_jam_log" in "/home/meerkoef/boost_regression/tools_regression/build"... # process_jam_log succesfully built in "/home/meerkoef/boost_regression/tools_regression/build/bin/gcc-3.4.3/release/process_jam_log" location # Making "/home/meerkoef/boost_regression/results" directory... # Starting tests ("/home/meerkoef/boost_regression/tools_bjam/bin.solarissparc/bjam" "-sBOOST_BUILD_PATH=/home/meerkoef/boost_regression:/home/meerkoef/boost_regression/tools_bb" "-sBOOST_ROOT=/home/meerkoef/boost_regression/boost" "--boost=/home/meerkoef/boost_regression/boost" "--boost-build=/home/meerkoef/boost_regression/tools_bb" "--debug-configuration" -l300 sun -d2 preserve-test-targets=off --dump-tests "--build-dir=/home/meerkoef/boost_regression/results" >>"/home/meerkoef/boost_regression/results/bjam.log" 2>&1)... # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 60, in ? runner(root) File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 193, in __init__ self.main() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 551, in main getattr(self,action_m)() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 516, in command_regression self.command_test() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 317, in command_test self.command_test_boost_build() File "/home/meerkoef/boost_regression/tools_regression_src/regression.py", line 354, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/home/meerkoef/boost_regression/results/boost/bin.v2/libs/any/test/any_test.test'

3 3

[Review] [ITL] ITL formal review results
by Hartmut Kaiser 29 Apr '10

29 Apr '10

Hi all, The formal review of the Interval Template Library (ITL) written by Joachim Faulhaber started February 18th and ended March 7th, 2010. We saw a lively discussion resulting in 14 votes: 10 people voted unconditionally YES, 3 voted conditionally YES, and 1 reviewer voted NO. The overwhelming majority of the votes was YES which reflects the overall discussion and the general consensus of this library being worth to be included into Boost. Based on this result and the discussions we saw the Interval Template Library is now formally accepted into Boost. Detailed results ---------------- Pros: Almost all reviewers highlighted the general usefulness of the library. The more experience the reviewers had with the library in real world applications the more they emphasized its usefulness. Here are some quotes: - "ITL solved this problem for me, in a way that honestly freed me from having to think about a lot of the unsavory low-level details." - " Until now, we only used the library for intervals of date-times (coded as integers), but I'm sure, that its usefulness goes far beyond." - " Very useful. I mentioned two projects where the library would have helped me if it had been into Boost earlier, and I'm considering rewriting them such that the problems make use of the library, and simplify them in that way." The comments on the quality of the documentation are unanimous: "impressive and quite complete", "I couldn't ask for more". It seemed to be generally helpful to understand the concepts of the library and to get started. Some people asked to add more simple quick-start examples to the documentation and the distribution. Overall, the library is mature and easy to use. All reviewers actually utilizing the ITL library for real world use cases reported they were able to start quickly and without problems. All reviewers using ITL in real world applications stated that no performance problems were encountered. This is important to note as the NO vote was based on the current lack of a interval tree implementation, which was considered to result in suboptimal performance for certain use cases. Cons: Some aspects of the design have been criticized: "OO-type design decisions", "fat 'one size fits all'-interval class template", and "incomplete extraction of global functions" are the major points of critique. These points have real merit. In order to make the design and interface more flexible and more durable these have to be rectified before the final inclusion of the library into Boost's code base. Joachim already agreed to a list of things to change addressing those problems. For certain use cases, specifically for interval map of collections, the current implementation has suboptimal complexity characteristics that leads to O(n^2) space usage in the worst case. OTOH, for the majority of applications of the library the worst case scenario seems to be (reportedly) irrelevant. This issue has been discussed at length and Joachim plans to add an implementation with a better worst case performance of the affected class templates as later optimizations. This is not considered to be a precondition to full inclusion into Boost's code base as it is not anticipated to cause any interface changes. Last but not least people suggested to change the name of the library as having the word template in the name does not carry any useful information. Joachim already agreed to this. Regards Hartmut Review Manager --------------- Meet me at BoostCon www.boostcon.com

3 3

About command line parameters parsing again...
by Denis Shevchenko 29 Apr '10

29 Apr '10

Hi all! Sorry for my English... During last two months I develop simple library for command line parameters parsing. Although there is many such libraries (e.g. on sf.net) I cannot find library with _realy_ simple using. Command line parameters parsing is simple, trivial task, so (imho) library for this task must be easy-to-learn and easy-to-use. Boost.Program_options is good and flexible library, but (imho) work with command line parameters must be easier. My library _not_ parse config file, because I like rule "one task - one library". My question: is it need in Boost another library for command line parameters parsing? P.S. Library: https://sourceforge.net/projects/clp-parser/ Denis

1 0

[range] irange is not very eloquent
by vicente.botet 29 Apr '10

29 Apr '10

Hi, I have find the function 'irange' in the section "Provided Ranges". template<class Integer> integer_range< range_detail::integer_iterator<Integer> > irange(Integer first, Integer last); I will expect in this section ranges and not functions. This function allows to treat integers as a model of the Random Access Range Concept. I find the name not very eloquent. What about make_integer_range, for example? BTW, I don't find the documentation of the the class integer_range. Where it is documented? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

3 10

[range] Permission to merge extensive documentation work from trunk.
by Neil Groves 29 Apr '10

29 Apr '10

Please may I merge just the documentation changes that have been performed on the trunk? These include: 1. corrections to documentation errors 2. complete documentation of the header files 3. acknowledgements for the Boost.RangeEx work. Regards, Neil Groves

3 6

[GSoC][boost.process] Blog
by Felipe Tanus 29 Apr '10

29 Apr '10

Hi, My project for Google Summer of Code was accepted, as many of you already know. I would like to give my thanks to anyone that supported me. I'll give my best in this project. Writing with my mentor, we decided that would be a good idea to keep an track from our actions, project decisions and have a place where interested people could help us without the need of we ask. Then, I created a blog that I'll write whenever I have something significant to tell. If you are interested in this project, I invite you to follow the updates from this blog[1] and comment whenever you like. This way, we might post in this mailing list only when it's strictly needed about the project. Thank you. [1] http://gsoc2010.fotanus.com -- Felipe de Oliveira Tanus E-mail: fotanus(a)gmail.com Blog: http://www.itlife.com.br Site: http://www.inf.ufrgs.br/~fotanus/ ----- "All we have to decide is what to do with the time that is given us." - Gandalf

1 0

[ANN] CodeSynthesis XSD 3.3.0 released
by Boris Kolpackov 29 Apr '10

29 Apr '10

Hi, I am pleased to announce the availability of CodeSynthesis XSD 3.3.0. CodeSynthesis XSD is an open-source (GPL2 + proprietary license), cross- platform W3C XML Schema to C++ data binding compiler. Provided with a schema, it generates C++ classes that represent the given vocabulary as well as parsing and serialization code. You can then access the data stored in XML using types and functions that semantically correspond to your application domain rather than dealing with elements, attributes, and text in a direct representation of XML such as DOM or SAX. The XSD compiler uses several Boost libraries (filesystem and regex) in its implementation. The generated code can also map XML Schema date/time built- in types to Boost date_time types. The C++ classes can also be serialized into various binary formats besides XML. Boost serialization library is supported as one of the representations. Major new features in this release: * Support for uniform parsing and serialization of XML documents with varying root elements. * Configurable application character encoding (UTF-8, ISO-8859-1, etc). * Support for stream-oriented, partially in-memory/partially event- driven XML parsing and serialization. * Support for embedding the binary representation of the schema grammar into the application. * Generation of the detach functions that allow moving object model sub-trees without copying. * Support for XML compression. * Smaller and faster generated code for polymorphic XML Schemas (xsi:type and substitution groups). The release also adds support for a range of new operating system and C++ compiler versions, including: * AIX 6.x * Mac OS X 10.6 * Windows 7, * Windows Server 2008 * Visual Studio 2010 (10.0) * GNU g++ 4.5.0 * Intel C++ 11 * Sun Studio 12.1 * IBM XL C++ 11 Visual Studio 2010 project and solution files are provided for all the examples. For the complete list of new features in this release see: http://www.codesynthesis.com/pipermail/xsd-announcements/2010/000038.html CodeSynthesis XSD is available on IBM AIX, GNU/Linux, HP-UX, Mac OS X, Solaris, Windows, OpenVMS, and z/OS. Supported C++ compilers include: GNU g++, HP aCC, IBM XL C++, Intel C++, Sun C++, and MS Visual C++. More information, documentation, source code, and precompiled binaries for all the supported platforms are available from: http://www.codesynthesis.com/products/xsd/ Boris -- Boris Kolpackov, Code Synthesis http://codesynthesis.com/~boris/blog Open-source XML data binding for C++ http://codesynthesis.com/products/xsd XML data binding for embedded systems http://codesynthesis.com/products/xsde Command line interface to C++ compiler http://codesynthesis.com/projects/cli

3 4

People in charge for the Boost-CMake mailing list
by Isidor Zeuner 29 Apr '10

29 Apr '10

Hello fellow Boosters, a couple of days ago I posted a message to the Boost-CMake mailing list and received a notification about the message awaiting moderator approval. Since then it was neither posted, nor did I receive a rejection notice. So I'm wondering if there is currently someone in charge of moderating this list, and if the message will expire at some point. Best regards, Isidor Zeuner

2 3