January 2012 - Boost - lists.preview.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Arguing about names in Boost libraries
by Edward Diener 06 May '15

06 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

[mpl] integral_c [type_traits] integral_constant limits
by vicente.botet 21 Oct '13

21 Oct '13

Hi, I was testing Boost.Ratio with gcc-4.6 c++0x and I get some compile errors when instantiating std::cout << boost::mpl::integral_c< boost::intmax_t, boost::integer_traits<boost::intmax_t>::const_max >::value ; ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:24:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a valid template argument for type 'long long int' because it is a non-constant expression ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a constant expression integral_wrapper.hpp:72 contains typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value + 1)) ) next; The same line pass with gcc-4.6, gcc-4.5 and gcc-4.5 c++0x with just a warning. ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:23:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] integral_c is by integral_constant, but integral_constant doesn't needs next a prior types. This means that with the current implementation we can not use integral_constant with the max value of the type. Do you think this is a bug in integral_constant? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 6

[asio] Randomly having problems reading from the socket
by Torben Wiggerich 29 Jul '13

29 Jul '13

Hi all, I have some problems using the boost.asio.read for a TCP-socket. So far it works fine, but it randomly stops the transfer for at least 5 seconds. To resolve the error I used a simple synchronous server and client from the boost examples and modified it too send a larger amount of data. (307400 Bytes; this size comes from the program I'm trying to get run). On the client side I also changed the reading from the socket to read the complete data with boost.asio.read and transfer_all as argument. Both, server and client, measure the time for sending and reading to the socket and will give an error if it needs more than 1 second. Here is the sourcecode for the server: #include <iostream> #include <string> #include <boost/asio.hpp> #include <boost/date_time/posix_time/posix_time.hpp> using boost::asio::ip::tcp; using namespace boost::posix_time; int main() { try { boost::asio::io_service io_service; tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 8002)); tcp::socket socket(io_service); acceptor.accept(socket); unsigned char * array = new unsigned char[307400]; for (;;) { boost::system::error_code ignored_error; ptime startTime = microsec_clock::universal_time(); boost::asio::write(socket, boost::asio::buffer( array, 307400 ), boost::asio::transfer_all(), ignored_error); time_duration neededTime = microsec_clock::universal_time() - startTime; if ( neededTime.total_milliseconds() > 1000 ) { std::cout << "ERROR needed too much time: " << neededTime.total_milliseconds() << "ms" << std::endl; } } } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } My client sourcecode: #include <iostream> #include <boost/array.hpp> #include <boost/asio.hpp> #include <boost/date_time/posix_time/posix_time.hpp> using boost::asio::ip::tcp; using namespace boost::posix_time; int main(int argc, char* argv[]) { try { if (argc != 2) { std::cerr << "Usage: client <host>" << std::endl; return 1; } boost::asio::io_service io_service; boost::asio::ip::tcp::endpoint endpoint( boost::asio::ip::address::from_string( argv[1] ), 8002 ); tcp::socket socket(io_service); boost::system::error_code error = boost::asio::error::host_not_found; socket.connect( endpoint, error ); if (error) throw boost::system::system_error(error); int counter = 0; unsigned char* array = new unsigned char[307400]; for (;;) { boost::system::error_code error; ptime startTime = microsec_clock::universal_time(); size_t len = boost::asio::read( socket, boost::asio::buffer( array, 307400 ), boost::asio::transfer_all(), error ); time_duration neededTime = microsec_clock::universal_time() - startTime; if ( error ) { printf( "body read error %s\n", error.message().c_str() ); } if ( counter % 5000 == 0 ) { std::cout << "passed: " << counter << "\r"; } ++counter; if ( neededTime.total_milliseconds() > 1000 ) { std::cout << "ERROR needed too much time: " << neededTime.total_milliseconds() << "ms" << std::endl; } } } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; } To reproduce the error just let it run for a while. It can take up to 30 minutes or even more... After a while it will produce the line: "ERROR needed too much time: 5007ms". Maybe with slightly different times, but all around 5 seconds. I tested it on different machines with Windows Vista and Seven. So am I'm doing sth. wrong? Is the reading from the socket correct? I'm using boost version 1.44. Kind regards Torben Wiggerich

6 11

De Bruijn Bind (alternate bind syntax) Interest?
by David Sankel 24 Jun '13

24 Jun '13

Hello all, I've been working on an alternate bind syntax based on De Bruijn indices[1]. The syntax is very simple, yet the terms are very powerful. Here is an example of a function const that takes in an argument c and returns another function that, for all input, returns c: //λx.λy.x = λλ1 with De Bruijn indices. auto const_ = abs<1>( abs<1>( var<1,0>() ) ); More examples, further explanation, and an implementation are available here[2]. I'm thinking that this library could also be useful as a core for more syntax heavy bind variations. David [1] http://en.wikipedia.org/wiki/De_Bruijn_index [2] http://bitbucket.org/camior/de-bruijn-bind/ -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

11 73

[config] consexpr workaround
by vicente.botet 21 Mar '13

21 Mar '13

Hi, in order to make easier the introduction of constexpr in a portable way I would like we add a Boost Config workarround. We can define some macros depending on whether BOOST_NO_CONSTEXPR is defined or not. #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #define BOOST_CONSTEXPR_OR_CONST const #else #define BOOST_CONSTEXPR constexpr #define BOOST_CONSTEXPR_OR_CONST constexpr #endif For most of the constexpr functions or constructors BOOST_CONSTEXPR will work. constexpr tuple(); =versus= BOOST_CONSTEXPR tuple(); When used for static constants BOOST_CONSTEXPR_OR_CONST is needed as we need to preserv the const keyword when consexpr is not available. static constexpr UIntType xor_mask = a; =versus= static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a; We could also add a STATIC_CONSTEXPR macro #define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTEXPR UIntType xor_mask = a; For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used. static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTANT(UIntType, xor_mask = a); Can we introduce this workaround? Best regards, Vicente _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

6 17

Fwd: [Thread] Solution to conflict with MFC?
by Thorsten Ottosen 28 Feb '13

28 Feb '13

Hi Thread maintainers, Anthony speaks about a patch to make this work. Does anyone know where it is? And could it be applied? Thanks -Thorsten -------- Original Meddelelse -------- Subject: [Thread] Solution to conflict with MFC? Date: Tue, 26 Apr 2011 13:28:56 +0200 From: Christian Larsen <contact(a)dword.dk> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org Newsgroups: gmane.comp.lib.boost.user Hello, I know this has been asked before, but I could not find a good solution. I'm experiencing problems with an application using both MFC and Boost.Thread. Specifically the assertion ASSERT(AfxGetModuleState() != AfxGetAppModuleState()); in AfxCoreInitModule() fails. I link Boost.Thread statically into a DLL in my project. From previous posts to this list and elsewhere, e.g. http://lists.boost.org/boost-users/2009/04/46929.php, I see that the issue is caused by setting _pRawDllMain in tss_pe.cpp. Commenting this line does "solve" the problem, but I would rather not have to hack the Boost source code this way. It seems there is a patch somewhere for this problem (referred to in http://lists.boost.org/boost-users/2009/04/47015.php) but it appears it never made it into the source. Is there any chance of this issue being solved in a better way? Best regards, Christian Larsen

5 9

[multi_index] Move Semantics
by Mark Snelling 27 Feb '13

27 Feb '13

Hi, I've been a user of Boost.MultiIndex for a number of years and think it's a great library. Is there any firm plan to add move semantics? It's been noted under "Future Work" in the docs since Boost 1.32. Regards, Mark

6 10

[parameter] std proposal
by Lorenzo Caminiti 07 Jan '13

07 Jan '13

Hello all, Is there a C++ standard proposal for named parameter addition? I am looking for an "N-paper" for named parameters similar to N2081 for concepts, or N1962 for contracts. Thank you. -- Sent from my mobile device Lorenzo

6 8

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[config] explicit call of operator templates / msvc bug workaround
by Stefan Strasser 10 Oct '12

10 Oct '12

Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan

6 10

[test] Trunk broken: What happened to test_exec_monitor?
by John Maddock 21 Sep '12

21 Sep '12

Testing on Trunk is apparently broken as the test_exec_monitor target has been removed from Boost.Test Trunk as of revision #74642. A quick grep shows 22 Jamfiles and over 200 targets dependent upon this. Whats happened? John.

14 68

[type_traits] has_equal_to< std::vector<T> > always true_
by lcaminiti 15 Jul '12

15 Jul '12

-- View this message in context: http://boost.2283326.n4.nabble.com/boost-type-traits-has-equal-to-std-vecto… Sent from the Boost - Dev mailing list archive at Nabble.com.

11 33

hex/unhex()?
by Olaf van der Spek 19 Jun '12

19 Jun '12

Hi, Does Boost have hex/unhex() that support std::string? I can't find them and I think they'd be quite handy to have. -- Olaf

7 35

status of sp_counted_base_solaris.hpp
by Graham Bennett 07 Jun '12

07 Jun '12

Hi all, I'm interested in getting boost::shared_ptr to use atomic ops on Solaris. I notice there is an implementation using the OS-provided atomics in boost/detail/sp_counted_base_solaris.hpp, but it doesn't seem to be included. According to this thread: http://lists.boost.org/Archives/boost/2006/07/107144.php, it seems the reason might be that it wasn't possible to come up with a proper preprocessor condition to include it on the right versions of Solaris. I'm considering modifying my boost installation to include this header on Solaris - does anyone know of any issues with the code, or can they confirm that it has been well tested? Are there any other reasons for its omission? Thanks, Graham -- Graham Bennett

4 7

[fusion] Trouble using BOOST_FUSION_ADAPT_ADT with boost::fusion::operator<
by GOODHART, TAYLOR 17 May '12

17 May '12

Hi all, I'm attempting to adapt a third-party struct into a fusion sequence using BOOST_FUSION_ADAPT_ADT to get access to a nice operator<. Unfortunately compilation fails and I'm not sure if it's a bug or me using the library incorrectly. As best I can read the error message, it looks like the code is attempting to compare adt_attribute_proxy structs instead of the values represented by these. Below is some code that demonstrates the problem. Can anybody help me out? Thanks, Taylor #include <boost/fusion/adapted/adt/adapt_adt.hpp> #include <boost/fusion/adapted/struct/define_struct.hpp> #include <boost/fusion/adapted/struct/adapt_struct.hpp> #include <set> #include <string> #include <boost/fusion/sequence/comparison/less.hpp> struct test1 { std::string s; const std::string & getS() const { return s; } void setS( const std::string & s_) { s = s_; } }; BOOST_FUSION_ADAPT_ADT( test1, (const std::string &, const std::string &, obj.getS(), obj.setS(val)) ) BOOST_FUSION_DEFINE_STRUCT( , test2, (std::string, s) (int, a) ) struct test3 { std::string s; }; BOOST_FUSION_ADAPT_STRUCT( test3, (std::string, s) ) using boost::fusion::operator<; int main( int argc, char * argv[]) { //Fails /*std::set<test1> destinations1; destinations1.insert(test1());*/ std::set<test2> destinations2; destinations2.insert(test2()); std::set<test3> destinations3; destinations3.insert(test3()); return 0; }

3 7

[contract] syntax redesign
by Lorenzo Caminiti 04 May '12

04 May '12

Hello all, After a long time of inactivity for Boost.Contract, I am considering how to re-design its macro syntax to make it simpler. I can eliminate a large number of extra parenthesis based on a few pp tricks I've learned in processing Boost.Local's `const bind(type)& var`. Plus, I can provide (optional) support for variadics macros so to use comma-separated pp tuplets instead of parenthesized pp sequences on preprocessors with variadics. For example, I _think_ (but I've not implemented this yet) that I can simplify the syntax like this: #include <contract.hpp> #include <vector> #include "myvector/pushable.hpp" // Wrapper class that adds contracts to std::vector. CONTRACT_CLASS( template( typename T ) class (myvector) extends( public pushable<T> ) // Subcontracting. ) { CONTRACT_CLASS_INVARIANT( empty() == (size() == 0) // More invariants here (comma separated)... ) CONTRACT_FUNCTION( public void (push_back)( (const T&) element ) precondition( size() < max_size() // More preconditions here (comma separated)... ) postcondition( auto old_size = CONTRACT_OLDOF(size()), // Old value. size() == old_size + 1 // More postconditions here (comma separated)... ) ) { vector_.push_back(element); // Implementation. } // Rest of the class here (with more contracts if needed)... public: typedef typename std::vector<T>::size_type size_type; size_type size(void) const { return vector_.size(); } size_type max_size(void) const { return vector_.max_size(); } bool empty(void) const { return vector_.empty(); } const T& back(void) const { return vector_.back(); } private: std::vector<T> vector_; }; For a side-by-side comparison with N1962 syntax: http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/inde… For a comparison of the entire std::vector (plus Boost.ConceptCheck concepts): http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/cont… For a comparison for all Boost.Contract features (plus Boost.ConceptCheck concepts and Boost.Parameter named parameters): http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/cont… (Don't pay attention to the rest of the docs that are way out of date.) A few notes: * Extra parenthesis are still needed around class and function names. * Extra parenthesis are still needed around types (like for the parameter `(T) element`) but only if the type is not a C++ keyword (no parenthesis needed aournd int, double, void, etc) or it contains a symbol (parenthesis needed if & or * are used `(int&) x`, etc). * In postconditions, the `auto old_size = CONTRACT_OLDOF(size())` only copies the vector size (and not the entire vector :)) ). Similarly, `auto result = return` can be used to access the return value for non-void functions. (The `auto ...` is parsed by the pp and it's implemented using Boost.Typeof so no C++0x is required.) * Template declaration (but not instantiation) angular parenthesis <> are replaced by round parenthesis (). All of this _should_ be implementable in pure ISO C++. What do you think? Based on the discontent that the previous "parenthesized" syntax generated among Boosters, the key question is: Would you consider this new syntax usable?? Thanks, --Lorenzo

5 45

Looking for some "real world" extended precision integer arithmetic tests
by John Maddock 23 Mar '12

23 Mar '12

Folks, I'm continuing to add to the multiprecision arithmetic library in the sandbox (under "big_number"), and I've just added a Boost licensed fixed-precision integer type which on Win32 at least looks to be very competitive with GMP for reasonable numbers of bits (up to about 1024), see http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… However, as we all know there are lies damn lies and performance stats ;-) Plus the test results I have above ignore the effect of memory allocations (needed by libtommath and GMP, but not the fixed_int code - which in theory should make it faster still). So I'd be really interested to put the type through it's paces with some real world code that really thrashes an extended precision integer type. Any suggestions? Anything in Boost? Thanks in advance, John.

5 38

[config] local types as template params
by Lorenzo Caminiti 22 Mar '12

22 Mar '12

Hello all, Is it possible to add a macro BOOST_CONFIG_LOCAL_TYPES_AS_TEMPLATE_PARAMS to Boost.Config to indicate if local types can be passed as template parameters? 1) Boost.Closure (formerly, Boost.Local) implements some optimizations when local types can be passed as template parameters. 2) C++11 always allows to pass local types as template parameters. 3) Local types cannot be passed as template parameters on C++03 instead but some C++03 compilers MSVC 8 (and older?) allow it anyway. // If it is possible to pass local types (classes, etc) as template parameters. // This is not possible in pure C++03 but it is possible in some C++03 // extensions (MSVC 8.0) and with C++11 (GCC >= 4.5.x -std=c++0x). #if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4)) && \ defined(__GXX_EXPERIMENTAL_CXX0X__) // From GCC 4.5.x when -std=c++0x specified. # define BOOST_LOCAL_TYPES_AS_TEMPLATE_PARAMS #elif defined(_MSC_VER) // For (all?) MSVC (tested on MVSC 8.0). # define BOOST_LOCAL_TYPES_AS_TEMPLATE_PARAMS #endif All, can you please try to compile the following example on different compilers/versions and let me know the outcome? If this example compiles successfully then the specific compiler supports local types as template parameters: #include <algorithm> #include <iostream> int main() { struct s { void operator()(int x) { std::cout << x << std::endl; } } l; int nums[] = {1, 2, 3}; std::for_each(nums, nums + 3, l); return 0; } For example, this compiles on GCC >= 4.5.x w/ C++0x extensions enabled and on MSVC 8.0- does it compile on all MSVC versions? Thanks. --Lorenzo

8 12

Re: [boost] size() type
by Olaf van der Spek 18 Mar '12

18 Mar '12

Hi, Any progress on these tickets? Would be nice to have a solution. size() return type should be size_type, not difference_type: https://svn.boost.org/trac/boost/ticket/5971 data() for iterator_range: https://svn.boost.org/trac/boost/ticket/5930 Greetings, -- Olaf

4 15

[range] adaptors and member functions pointers
by Yanchenko Maxim 17 Mar '12

17 Mar '12

Hi, While transforming and filtering sequences, it's pretty common to call the elements' member functions, so I think it's worth adding some syntactic sugar for range adaptors in order to achieve cleaner syntax. E.g. if we have a class struct Foo { std::string description() const; }; and we want to get all non-empty descriptions, we could just write this clean code: foo_list | transformed(&Foo::description) | filtered(&std::string::size) To enable this syntax, the attached patch should be applied to boost/range/adaptor/argument_fwd.hpp (diff against 1.47.0). Is there any interest to add this to Boost.Range? Thanks, Maxim

7 9

Determining interest: Pure imaginary number library
by Matthieu Schaller 29 Feb '12

29 Feb '12

Dear all, I have recently been playing a lot on numerical analysis problems containing complex numbers and functions. I have been using the SL std::complex<> library and could observe that some of the algorithms weren't optimized in cases where complex numbers have to be multiplied by pure imaginary numbers (i.e. x*sqrt(-1)). I have implemented a class to represent these numbers and overloaded all relevant operators in a more optimized fashion thanks to the knowledge that the real part of these complex numbers is 0. I could observe an important speed-up in some calculations. As an example, this piece of code (1D Schroedinger equation using finite differences): for(size_t i(0); i<nbPoints; ++i) { Psi_new[i] = Psi_old[i] + ii * hbar * deltaT / (12.*m*deltaX*deltaX) * (-Psi_cur[i-2] + 16.*Psi_cur[i-1] - 30.*Psi_cur[i] + 16.*Psi_cur[i+1] - Psi_cur[i+2]) - 2. * ii * V(x[i]) / hbar * deltaT * Psi_cur[i]; } is more than 2 times faster (g++ 4.6.1 core i7 2820QM) when the imaginary unit (constant) variable ii is defined to be Imaginary<double> ii(1.); than when it is defined as std::complex<double> ii(0.,1.); Some other expressions also benefit from this improvement and can run faster. Expressions including square roots or exponentials of pure imaginary numbers are improved a lot. The range of application of such a class is quite narrow but it may be helpful to speed-up some simple numerical problems. The source code as well as a working example is available here: http://code.google.com/p/cpp-imaginary-numbers/ Thanks, Matthieu

8 21

vsix - template_profiler extension
by Brandon Kohn 27 Feb '12

27 Feb '12

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

5 16

[move] new rvalue reference emulation
by Jeffrey Lee Hellrung, Jr. 19 Feb '12

19 Feb '12

I've recently discovered (well, probably rediscovered) an alternate rvalue reference emulation, one which allows rvalues ***of any arbitrary (move-emulation-enabled) type*** to be captured in C++03 and identified as rvalues, rather than references-to-const (there is a drawback, though, which I'll get to below; as usual, there's no "free lunch"). This is in contrast to the current move emulation framework Ion has created in Boost.Move which, at best, allows you to capture rvalues of specific types. That is, if you can enumerate the types for which you want to enable rvalue capture, then you're good. For example, if you want to create a generic unary function some_fn, and you know you want to at least capture rvalues of type X, you could do: template< class T > void some_fn(T&); // captures (lvalue) references-to-non-const, explicitly created emulated rvalue references, *and* (lvalue) references-to-(X const) template< class T > typename boost::disable_if< boost::is_same<T,X> >::type void some_fn(T const &); // captures (lvalue) references-to-const *except* (lvalue) references-to-(X const) void some_fn(rv<X>&); // captures rvalues of X as emulated rvalue references However, if Y is any type other than X, the above overloads will capture an rvalue of Y as an (lvalue) reference-to-(Y const). This is one of the shortcomings of using the emulated rvalue reference rv<T>& as a function argument: it can't bind to rvalues in a context where the template parameter T is deduced. Now I don't know if the following proposition is a good idea or not, but I think it is worth considering. Again, we would like the emulated rvalue reference rv<T>& to bind to rvalues, but the problem is the deduction of the T template parameter. Instead of using rv<T>& to capture arbitrary rvalues, I'll use a kind of type-erased emulated rvalue reference, generic_rv<...> (for lack of a better name at the moment), which will just store a void pointer to the original, pre-type-erased object. Of course, we need some way to recover the object back from the void pointer, and that's what the "..." template parameters are for. This is where the (unfortunate) runtime overhead comes in, as some dispatching mechanism (e.g., function pointers) needs to be used to effect the recovery of the original, pre-type-erased object. The important difference between rv<T> and generic_rv<...> is that there's no T in the template parameter list "..." of generic_rv; more to the point, its template parameters are not deduced within the context of binding function arguments of some_fn, hence the compiler will be allowed to look for conversions from arbitrary rvalues to generic_rv<...>. Hopefully that gives enough of an introduction to the idea. Further details are probably best left to a code snippet. Comments? Specifically, should this be considered as an addition to Boost.Move's current emulation framework? Has anyone seen this technique before? ---------------- #include <iostream> #include <boost/type_traits/is_convertible.hpp> #include <boost/utility/enable_if.hpp> // rv<T>& emulates T&& template< class T > class rv : public T { rv(); rv(rv const &); rv& operator=(rv const &); }; template< class T > struct has_move_emulation : boost::is_convertible< T, rv<T>& > { }; // *** NEW EMULATED RVALUE REFERENCE *** // generic_rv< F, Result > also emulates an rvalue reference, but in a kind of // type-erased way. The actual object referred to is referenced by a void // pointer. To be able to cast the void pointer back to a pointer-to-object, we // need to package the void pointer together with some kind of dispatching // mechanism. We use a function pointer to an instantiation of cast_forward<T>. template< class F, class Result = void > struct generic_rv { typedef Result (*p_cast_forward_type)(F, void*); generic_rv(p_cast_forward_type p_cast_forward, void* p) : mp_cast_forward(p_cast_forward), m_p(p) { } Result cast_forward(F f) const { return (*mp_cast_forward)(f, m_p); } template< class T > static Result cast_forward(F f, void* const p) { return f(static_cast< rv<T>& >(*static_cast< T* >(p))); } private: p_cast_forward_type mp_cast_forward; void* m_p; }; // X is just a typical move-emulation-enabled class. struct X { X() { std::cout << "X::X()" << std::endl; } X(X const &) { std::cout << "X::X(X const &)" << std::endl; } X(rv<X>&) { std::cout << "X::X(rv<X>&)" << std::endl; } X& operator=(X) { std::cout << "X::operator=(X)" << std::endl; return *this; } X& operator=(rv<X>&) { std::cout << "X::operator=(rv<X>&)" << std::endl; return *this; } operator rv<X>&() { std::cout << "X::operator rv<X>&()" << std::endl; return *static_cast< rv<X>* >(this); } operator rv<X> const &() const { std::cout << "X::operator rv<X> const &() const" << std::endl; return *static_cast< rv<X> const * >(this); } // *** NEW CONVERSION OPERATOR *** // X provides an implicit conversion to generic_rv. template< class F, class Result > operator generic_rv< F, Result >() { std::cout << "X::operator generic_rv< F, Result >()" << std::endl; return generic_rv< F, Result >( &generic_rv< F, Result >::template cast_forward<X>, static_cast< void* >(this) ); } }; struct some_fn { template< class T > void operator()(T&) const { std::cout << "some_fn::operator()(T&) const" << std::endl; } template< class T > typename boost::disable_if< has_move_emulation<T> >::type operator()(T const &) const { std::cout << "some_fn::operator()(T const &) const" << std::endl; } // Notice that this overload requires template parameter deduction, hence // the compiler cannot apply an implicit conversion to rv<T>& from rvalues // of move-emulation-enabled types. In other words, this overload can only // bind to *explicitly* created emulated rvalue references, not to "real" // rvalues :( template< class T > void operator()(rv<T>&) const { std::cout << "some_fn::operator()(rv<T>&) const" << std::endl; } // *** NEW FUNCTION OVERLOAD TO CAPTURE RVALUES *** // Since this overload requires no template parameter deduction, the // compiler *can* apply an implicit conversion to generic_rv<...> from // rvalues of move-emulation-enabled types. Yes, there will be some runtime // overhead from the function pointer dispatching, but that will often be // preferable to copying x! void operator()(generic_rv< some_fn > const x) const { std::cout << "some_fn::operator()(generic_rv< some_fn >) const" << std::endl; return x.cast_forward(*this); } }; template< class T > T make() { return T(); } int main(int argc, char* argv[]) { int a = 0; int const b = 0; some_fn()(a); // some_fn::operator()(T&) const some_fn()(b); // some_fn::operator()(T const &) const some_fn()(make< int >()); // some_fn::operator()(T const &) const X x; // X::X() X const y; // X::X() some_fn()(x); // some_fn::operator()(T&) const some_fn()(y); // some_fn::operator()(T&) const some_fn()(make<X>()); // X::X() // X::operator generic_rv< F, Result >() // some_fn::operator()(generic_rv< some_fn >) const // some_fn::operator()(rv<T>&) const return 0; } ---------------- - Jeff

10 33

[optional] generates unnessesary code for trivial types
by Hite, Christopher 12 Feb '12

12 Feb '12

When decompiling my code I noticed a bunch of unnessesary code caused by boost::optional. 1) deconstruction typedef boost::optional<int> optional_int; void deconstruct_boost_optional(optional_int& o){ o.~optional_int(); } One would expect this to do nothing. Instead gcc 4.6.0 with O3 generates: if(m_initialized){ // do nothing m_initialized = false; } 00000000 <deconstruct_boost_optional(boost::optional<int>&)>: 0: 8b 44 24 04 mov 0x4(%esp),%eax 4: 80 38 00 cmpb $0x0,(%eax) 7: 74 03 je c <deconstruct_boost_optional(boost::optional<int>&)+0xc> 9: c6 00 00 movb $0x0,(%eax) c: f3 c3 repz ret This one could be easily fixed by removing the bit that sets m_initialized to false, since we're deconstructing anyway. 2) assignment also generates these problems: void assign_boost_optional(optional_int& o){ o=13; } Here there's a semantic issue: we have to decide to use the copy constructor or operator=. This is also wasteful for POD types or any type which has_trivial_copy<>. 3) Even more expensive is if we want to copy an optional<int> void assign_boost_optional(optional_int& a,optional_int& b){ a=b; } 00000000 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)>: 0: 8b 44 24 04 mov 0x4(%esp),%eax 4: 8b 54 24 08 mov 0x8(%esp),%edx 8: 80 38 00 cmpb $0x0,(%eax) b: 74 0b je 18 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x18> d: 80 3a 00 cmpb $0x0,(%edx) 10: 75 16 jne 28 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x28> 12: c6 00 00 movb $0x0,(%eax) 15: c3 ret 16: 66 90 xchg %ax,%ax 18: 80 3a 00 cmpb $0x0,(%edx) 1b: 74 09 je 26 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x26> 1d: 8b 52 04 mov 0x4(%edx),%edx 20: c6 00 01 movb $0x1,(%eax) 23: 89 50 04 mov %edx,0x4(%eax) 26: f3 c3 repz ret 28: 8b 52 04 mov 0x4(%edx),%edx 2b: 89 50 04 mov %edx,0x4(%eax) 2e: c3 ret Three possible branches! Theoretically single 64 bit copy do the job. I'm tempted to say: it would be best if for any T has_trivial_copy< optional<T> > iff has_trivial_copy<T>. It might make a sense to make an exception for huge T, where the copying an unused T is more expensive than the branching. 4) has_trivial_destructor<T> should impl has_trivial_destructor< optional<T> > , but this is hard to implement without specialization of optional. Checking has_trivial_destructor might take care of the complexity of optional<T&> since has_trivial_destructor< T& >. I'd be willing to fix #1. The other issues need some discussion. Chris

14 39

How to make tests building faster?
by Mateusz Łoskot 10 Feb '12

10 Feb '12

Hi, I'm trying to figure out if there is anything I could do to improve compile/link-time for tests of Boost.Geometry library. Currently, the tests follow fairly canonical approach in Boost: 1) Each .cpp file defines a single test program and all local test routines are executed from test_main() // test_feature_x.cpp void test1() {} // make use of BOOST_CHECK_* macros void test2() {} int test_main(int, char* []) { test1(); test2(); return 0; } 2) Jamfile per testing project builds and runs each program separately # features/Jamfile.v2 test-suite test-features : [ run test_feature_x.cpp ] [ run test_feature_y.cpp ] ; 3) Root mylib/test/Jamfile.v2 defines testing projects to build and run import testing ; project boost-mylib-test : ; build-project features ; build-project algorithms ; build-project abc ; In total, there are nearly 170 test programs in Boost.Geometry. Obviously, running the whole set of tests (b2 command issued in libs\geometry\test) is time consuming process. I'm wondering if there is any way to reorganise the tests to cut down the build (linking) time. My first idea is to decrease number of run entries (e.g. [ run test_feature_y.cpp ] ) in Jamfiles, by building related tests as single test suite program. Conceptually: [ run test_feature_x.cpp test_feature_y.cpp ] Currently, there is no use of Boost.Test features for tests organisation like BOOST_AUTO_TEST_CASE BOOST_TEST_SUITE etc. I wonder if use of any of the above would help in restructuring tests and decreasing number of programs to build. Another aspect of Boost.Geometry tests I'd like to improve is to improve tests report output. Currently, it is reported as *Passed* or *Failed*. I presume that using Boost.Test to group tests in suits with test cases would improve test report providing details about location of failure (which suite, which case, or even better). I'm looking for any piece of advice on the issues discussed above: - How to cut down build time of tests? - How to improve test output report (and keep it suitable for Boost regression testing framework)? - Is it advised to switch to use Boost.Test features to manage suites and test cases? (I tried to figure it out browsing tests of other libs, but it doesn't indicate any preferred practice). I'd be thankful for any insights. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

10 34

[hash] regular behaviour of hash function for double values
by Kai Schroeder 07 Feb '12

07 Feb '12

Hi, the following code: double fStart = 31337; double fEnd = 65536; double fStep = fStart - fEnd; fStep /= 512; for (int i = 0; i < 512; i++) { std::cout << std::hex << boost::hash<double>()(fStart + i * fStep) << std::endl; } leads to the output of surprisingly regular hash values (see end of mail). This seems to occur mainly if a power of two number of points is sampled equidistantly within an interval. Especially since some hash table implementations (e.g. intel's threading building blocks) only use the last few bits to determine the bucket, this can lead to very bad caching behaviour for the rather common case of regularly sampled points (equidistant samplings of power of 2 are e.g. common in computer graphics and numerical algorithms). Are you aware of this? Would you consider it a bug? Best regards, Kai Schroeder Output of code using Boost 1.48 (similar behaviour can be observed for other start and end values and other power of 2 step counts): ff9f20000000000f e5042f900000000f 52f13f200000000f 297ac8b00000000f 48721e400000000f 2f9b8dd00000000f 3df0b1600000000f d19cf2f00000000f 9201c800000000f 9409aa100000000f 7cb3fba00000000f d7a42b300000000f b15982c00000000f 5f7900500000000f e0ba85e00000000f 255ee5700000000f cec119000000000f 955bd6900000000f 6a58f4200000000f 843a37b00000000f 590797400000000f 7e8db4d00000000f 1721b6600000000f 37acf9f00000000f df5f65800000000f 88b1a5100000000f 494a0a00000000f bb1082300000000f 1ea62bc00000000f ...

11 43

unordered_map 32bit VS 64bit
by Avikam Bara-nes 07 Feb '12

07 Feb '12

Hi, I'm porting a project from Linux 32bit to Linux 64bit. While doing so I notice that I have a dramatic performance degradation with unordered_map. My platform is Ubuntu 10.4.3 64bit running on Intel Xeon X3220 but, I tested similar program on WindowsXP SP2 64bit which running on Intel i5 and I get the same degradation. My boost version is 1_46_1. I use the following program in order to test unordered_map - Hop I didn't make any copy mistakes :-). #include <stdio.h> #include <sys/time.h> #include <boost/unordered_map.hpp> int main(int argc, char *argv[]) { struct timeval tv_before, tv_after; boost::unordered_map<boost::int_32_t, boost::int32_t> boost_map; boost_map[1] = 2; boost_map[3] = 4; gettimeofday(&tv_before, NULL); for(int i = ; i < 100000; i++) boost_map.find(1); gettimeofday(&tv_after, NULL); printf("Boost time is %f \n", (double)(((tv_after.tv_sec - tv_before.tv_sec) * 1000000 + (double)(tv_after.tv_usec - tv_before.tv_usec)) / 100000)); return 0; } I use the following compile commands: 64bit - g++ -O3 perf_test -o perf_test_64bit 32bit - g++ -m32 -O3 perf_test -o perf_test_32bit When I run the 32bit program I get 0.5 sec When I run the 64bit program I get 1.54 sec Any ideas ???

6 16

[functional] adding overload
by Lorenzo Caminiti 06 Feb '12

06 Feb '12

Hello all, During Boost.Local review, it was proposed to move the overload template out of Local and in Boost.Functional. What would the best name for it? 1) boost::overload_function (my preference) 2) boost::overloaded_function 3) boost::function_overload 4) boost::functional::overload (Boost.Functional seems to use boost:: directly and not boost::functional-- to mimic C++11 <functional>). For example: void print_text(char const* text) { std::cout << text << std::endl; } void print_add(int x, int y = 10) { std::cout << (x + y) << std::endl; } boost::function<void (int, int)> f = print_add; boost::overload_function< void (char const*) , void (int, int) , void (int) > print(print_text, f, print_add); print("abc"); // abc print(1, 2); // 3 print(1); // 11 Docs: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… Thanks. --Lorenzo

8 18

[filesystem] windows/posix inconsistencies.
by Thorsten Ottosen 06 Feb '12

06 Feb '12

Hi Beman, I noticed the following in v3 whie hunting down a bug in my unit test: # ifdef BOOST_WINDOWS_API const std::string string() const { return string(codecvt()); } const std::string string(const codecvt_type& cvt) const; // string_type is std::wstring, so there is no conversion const std::wstring& wstring() const { return m_pathname; } const std::wstring& wstring(const codecvt_type&) const { return m_pathname; } # else // BOOST_POSIX_API // string_type is std::string, so there is no conversion const std::string& string() const { return m_pathname; } const std::string& string(const codecvt_type&) const; const std::wstring wstring() const { return wstring(codecvt()); } const std::wstring wstring(const codecvt_type& cvt) const # endif I can understand, that it is more efficient to return a reference when a referenec can be formed. However, consider const std::string& ext = iter->path().extension().string(); This is fine on windows, as a temporary is returned, and its lifetime is extended; on linux, extension() returns a temp path object, from where we get a reference. I'm not a 100% sure, but I think the C++ standard does not guarantee that this path object be kept alive. The net efffect is a crash on linux. I'm not sure its a great idea to have different reference-ness on the return types here. It could lead to other subtle differences. kind regards -Thorsten

9 14

[mpl] Nested Scopes w/Placeholders
by Kitten, Nicholas 06 Feb '12

06 Feb '12

I've recently been doing a lot mpl::folding (in boost 1.47), and I was disappointed when I realized that a nested fold wouldn't work with a lambda expression passed to the inner call, as in this example which extracts elements of sequences: using namespace mpl; using namespace mpl::placeholders; typedef vector< vector<char>, vector<int> > vec_of_vecs; typedef vector< char, int > expected_result; typedef fold< vec_of_vecs, vector<>, fold< _2, _1, *push_back< _1, _2 >* // wrong - refers to outer arguments > >::type result; BOOST_MPL_ASSERT(( equal<result, expected_result> )); After looking around for a solution I came across an old thread<http://lists.boost.org/boost-users/2004/12/9269.php> on the same subject, where it was suggested using mpl::protect might work. Indeed, the following modification does what I want, without any changes to the library: typedef fold< vec_of_vecs, vector<>, fold< _2, _1, *protect< lambda< push_back< _1, _2 > >::type >* // correct > >::type result; Of course, this is a little on the verbose side. In the old thread, Daniel Wallin suggested suggested changing the definition of lambda to yield syntax more in line with the runtime version of boost::bind, but that would apparently break other code. What about instead adding a specialization to protect for placeholder expressions? Indeed, the source in protect.hpp seems to indicate such a thing might've been in the works at one point, but I didn't see any more references to it: template< typename BOOST_MPL_AUX_NA_PARAM(T) * , int not_le_ = 0 // not lambda expression?* > struct protect : T { ... typedef protect type; }; What about changing it to something like this? template< typename BOOST_MPL_AUX_NA_PARAM(T) * , typename not_le_ = typename is_lambda_expression< T >::type* > struct protect : T { ... typedef protect type; }; *template< typename T >* *struct protect< T, mpl::true_ > : lambda<T>* *{* *...* *typedef protect type;* *};* Doing so would remove the inner lambda<...>::type expression, yielding the expected syntax. Could that be done without messing up everything else? Thanks, *Nick Kitten* Software Engineer Center for Video Understanding Excellence ObjectVideo, Inc.

3 6

1.49.0 Beta 1 Release Candidate
by Steve M. Robbins 04 Feb '12

04 Feb '12

Hi, I'm starting a build (using the Debian package configuration) and noticed several known bugs still present: These two bugs are patched on the trunk but not release. Can these be moved over, please? https://svn.boost.org/trac/boost/ticket/4657 https://svn.boost.org/trac/boost/ticket/6338 This issue has a simple patch that works around the problem for gcc versions prior to 4.6.3: https://svn.boost.org/trac/boost/ticket/5538 This issue has a patch that works (is used in Debian), though a jam expert could likely find a better fix: https://svn.boost.org/trac/boost/ticket/6286 Regards, -Steve (Boost maintainer for Debian)

5 9

[random] Determining interest in Pseudo-Random Functions and Counter Based Random Number Generators
by John Salmon 03 Feb '12

03 Feb '12

I am co-author of "Parallel Random Numbers, as Easy as 1, 2, 3". which recently won the best paper award at the IEEE/ACM SC'11 conference. I'm also co-author of the related Random123 library: http://deshawresearch.com/resources_random123.html My colleagues and I would like to contribute a similar library to Boost as well. This isn't just a "port" of the Random123 library. Boost's focus on C++ allows for both simplification and clarification of the ideas in the paper and the original library. I've done a preliminary draft of some code that fits nicely into the existing Boost Random library. It's incomplete, but I think there's enough for folks to look at and gauge further interest. A zip file with a boost-like layout is here: http://thesalmons.org/john/random123/prf_boost/prf_boost.zip The README from the zip file is appended. I look forward to your comments and suggestions. John Salmon -------------- README ------------------- This extension of the Boost Random library adds "Pseudo-Random Functions" (PRFs) as an alternative to conventional "Uniform Random Number Generators" and "Random Number Engines". It is an incomplete draft, intended to start a conversation. It is not ready-to-use library. The case for using PRFs in Monte Carlo and statistical simulation is given in the paper, "Parallel Random Numbers -- As Easy as 1, 2, 3", by Salmon, Moraes, Dror & Shaw, in the Proceedings of SC'11: http://dl.acm.org/citation.cfm?doid=2063405 also available at http://www.thesalmons.org/john/random123/papers/random123sc11.pdf PRFs have been known for many years, but either their advantages were unrecognized or they were thought to have poor performance with respect to conventional URNGs. The paper shows that PRFs exist with excellent statistical properties, and highly desirable space and time characteristics. Also, note that the terminology in the paper, is slightly different from that used here. In the paper they're called "Counter Based Random Number Generators". PRFs are well-known in cryptography, but the PRFs here (except for AES) are *not* cryptographically strong. Nevertheless, they have satisfied extensive tests of statistical quality and should satisfy the needs of Monte Carlo simulation and other fields that routinely use random numbers. PRFs are pure functions (functors in C++) with the property that they return "random" values, even when presented with highly regular inputs (see the paper for a discussion of how randomness is empirically established). The user of a PRF assembles the input, calls the function and obtains a "random" result which can then be used in the same way as a value obtained from a conventional URNG or Engine. In contrast, a conventional Random Number Engine has a much more limited API: the caller is restricted to seeding the engine, once and for all, and then repeatedly asking for the "next" random value. PRFs eliminate the sequential dependence inherent in conventional RNGs. With a PRF, one can compute the "n-th" value in O(1) time, without stepping through earlier values. In fact, with a PRF, the notion of an "n-th" value loses its significance. One simply obtains a random value. Eliminating sequential dependence can be especially useful for parallel, multi-threaded applications. For example, one can assemble a PRF's input from application-level data, e.g., object id, voxel number, user-supplied seed value, timestep, iteration number, etc. This kind of application data is unchanged when the application is parallelized, and is generally invariant as more or fewer threads become available. The resulting random value is thus invariant to the parallelization as well. This can be enormously helpful when correctness dictates that separate "parallel" threads should use the same "random" value, or when trying to reproduce results on different platforms with different levels of parallelism. Four PRFs are implemented: threfry, philox, ars and aes, each implemented in its own header file, e.g., boost/random/ars.hpp. The file boost/random/counter_based_urng.hpp implements the counter_based_urng adapter class, which creates a Uniform Random Number Generator from a PRF, allowing programmers to use the PRF APIs together with Boost or C++1x Random Number Distributions. The file boost/random/counter_based_engine.hpp implements the counter_based_engine adapter class, which creates a Uniform Random Number Engine from a PRF, allowing PRFs to be used with software that relies on the Uniform Random Engine concept. For better or worse, wrapping a PRF in a counter_based_engine adapter completely obscures the PRF's API and reintroduces sequential dependence. The zip file also contains a copy of the candidate Boost Endian library copied from boost sandbox. Endian-swapping is required by the AES engine on bigendian machines, and the library meets our needs. Concepts -------- All PRFs have a domain_type and a range_type and with d a "permissible" object of the domain type, the expression: prf(d) is of the range_type. In many cases, every possible value of domain_type will be "permissible", but we leave open the possibility that the prf may place restrictions on the values of domain_type that produce "random" results. The values returned by the prf should be "random", a concept that is difficult to make both precise and achievable. Roughly, for most sequences, including highly "regular" sequences, of distinct, permissible domain_type values, d1, d2, d3, ..., the sequence: prf(d1), prf(d2), prf(d3), ... is statistically indistinguishable from a sequence of independent, uniformly distributed random variables sampling the range_type. In most cases, the output of the prf will uniformly sample all possible values of the range_type, but we leave open the possibility that it may only sample a subset and that the output is only uniform over the subset. Keyable PRFs have a key_type, a corresponding constructor, and setkey() and getkey() member functions. Keyable PRFs constructed with different keys must also be statistically independent. I.e., even for highly regular sequences of distinct (key, domain) pairs: (k1, d1), (k2,d2), ... the sequence: Prf(k1)(d1), Prf(k2)(d2), ... is statistically indistinguishable from a sequence of independent random uniformly distributed samples of the range_type Keyable PRFs may also be Seedable in which case they also have seed() member functions and corresponding constructors similar to those of Random Number Engines. Seeding a PRF is equivalent to setting its key to some value corresponding to the output of sseq.generate(). A PRF has a Countable Domain if its domain_type has member functions begin(), end(), and back() with semantics identical to that of boost::array<Uint, N> for some unsigned integral type Uint and some N. It must also have member functions domain_array_min() and domain_array_max() that specify the permissible domain values. Any array, da, whose members, da[i], satisfy: prf.domain_array_min() <= da[i] <= prf.domain_array_max[] must be "permissible". A PRF has an Integer Array Range if its range_type has member functions begin(), end(), and size() with semantics identical to boost::array<RangeInt, N>, for some integral type, RangeInt and constant N. It must also have static constexpr member functions, range_array_min() and range_array_max() that specify the subset of range values sampled by the PRF. For any sequence of permissible domain value, d1, d2, ..., the integers: prf(d1)[i], prf(d2)[i] must be statistically indistinguishable from independent uniformly distributed RangeInts from range_array_min() up to and including range_array_max(). If a PRF has a Countable Domain and an Integer Array Range, then: counter_based_urng<Prf> satisfies the requirements of a Uniform Random Number Generator. If, in addition, the PRF is Seedable, Streamable and Equality Comparable, then: counter_based_engine<Prf> satisfies the requirements of a Random Number Engine. A PRF is a Pseudo-Random Bijection if it is one-to-one and onto. I.e., if it has an inverse. It is not necessary for the inverse to have a practical implementation. It is sufficient that the inverse exist mathematically. A PRF is a Pseudo-Random Permutation if it is a Bijection and its domain_type is the same as its range_type. The four implemented PRFs are CopyAssignable, EqualityComparable, Streamable, Keyable, Seedable, Pseudo-Random Permutations with Integer Array ranges and Countable domains. Hence, they satisfy the requirements of counter_based_engine and counter_based_urng. Differences from Random123 -------------------------- This code is inspired by the Random123 library, but there are significant differences. New terminology: threefry<2, uint64_t> is a "Pseudo-Random Function" (PRF). PRFs take a key_type as a constructor argument, and are bijections on their ctr_type. Thus, instead of: typedef r123::Threefry2x64 r123_t; r123_t::ctr_type c; r123_t::key_type k r123_t::ctr_type r = r123_t(c, k) You now say: typedef boost::random::threefry<2, uint64_t> prf_t; prf_t::key_type k; prf_t myprf(k); prf_t::domain_type c; prf_t::range_type r = myprf(c); // Or alternatively, (more reminiscent of Random123) prf_t::range_type r2 = prf_t(k)(c); AESNI ----- Use of AESNI is tricky because we want both compile-time and runtime control over whether AESNI is used. The compile-time control is determined by BOOST_HAS_AESNI, which we assume will be set by some config file based on compiler-specific symbols (__AES__, __x86_64__, __ICC, __GNUC__) and possible user-overrides. But even if AESNI support is compiled in, we have to detect it and fall back to a software implementation at runtime if it's not available. The check requires either an asm with GCC-compatible compilers or an intrinsic with MSVC-compatible compilers. Endianness is another complication. The AESNI implementation only works on x86_64 platforms, so it is not endian-sensitive. In fact, it *defines* how multi-byte quantities are to be interpreted. In contrast, the software implementation has to be endian-aware. The current implementation has not been tested with other endians, and hence is almost certainly broken. And finally, the AESNI intrinsics are *very* fast. We don't want to weigh them down with lots of runtime checks. With AESNI enabled, the runtime overhead should cost no more than a single conditional at the top of operator()(c). The choice between hardware and software AES is controlled by a member data field, useAESNI, of the prf class. If hw AES is compiled in, useAESNI is initialized by a runtime check of the CPU capabilities. It can be changed with a mutator method. If hw AES is not compiled in, useAESNI is initialized false and it is an error to try to set it to true. In detail/aes_impl.hpp, we implement two classes: detail::hw128 detail::sw128 with a common interface that minimally meets the needs of AES and ARS. The interface includes +=, ^= constructors from array<uintW, N>, aesenc, and aeskeygenassist primitives, etc. The crucial functions in AES and ARS are then written with a template parameter that is assumed to provide the interface. An idiom like: #if BOOST_HAS_AESNI if( useAESNI ) method<detail::hw128>(args); else #endif method<detail::sw128>(args); gives the desired compile-time and runtime control.

7 10

[metagraph]
by Kitten, Nicholas 03 Feb '12

03 Feb '12

Hi Gordon (and whoever else is involved), What's the current status of metagraph / mpl_graph? I've been using msm::mpl_graph for error-checking/scheduling in a compile-time filter graph framework (similar to state machines, but focus is on data flow), and I'd certainly like to see more. As is, I've already implemented a topological sort based on the BFS which doesn't yield errors on cyclic graphs (which I'd be happy to contribute if you don't already have one), and I have some thoughts on improvement. I saw the BoostCon slides and the current state of the sandbox, and I was wondering if there's more code lurking out there somewhere, unchecked-in. Anyway, the single biggest flaw I see with the current BFS and DFS (and the BGL models they're based on) is that there is no way for the user to specify a termination condition in the base algorithm. It seems silly that an algorithm called "Search" can't end without traversing the whole connected component! Indeed, if there were simply an optional predicate determining whether a candidate vertex should be added to the stack/queue, I wouldn't have needed to write a separate algorithm for topo sort. The other thing is that not all of the listed visitor operations are called in the current implementations. Adding things like "initialize_vertex" and "non_tree_edge" to BFS is an easy fix. Thanks, Nick Kitten Software Engineer Center for Video Understanding Excellence ObjectVideo, Inc. http://www.objectvideo.com

3 6

[1.49.0] New libraries in 1.49.0?
by Beman Dawes 02 Feb '12

02 Feb '12

What are the new libraries in 1.49.0? --Thanks, --Beman

5 8

[interprocess] utf8 file names in memory mapped files
by Thorsten Ottosen 01 Feb '12

01 Feb '12

Hi Ion, It would be great if we could support utf8 encoded file names on windows too. I guess all it requires is a utility function that converts from utf8 to utf16 on windows. Such a function is avaiable in the windows API, and I can supply it. kind regards Thorsten

3 6

[1.49.0] Beta 1 release candidates available
by Beman Dawes 01 Feb '12

01 Feb '12

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

19 32

[1.49.0] Branches/release open for bug fixes and documentation updates
by Beman Dawes 01 Feb '12

01 Feb '12

branches/release is now open for bug fixes and doc updates, without need to ask for a release manager's permission. It will remain open until Monday, February 13th. The final release is scheduled for February 20th. The hope is that this somewhat longer beta period will allow time to fix more bugs that surface during the beta period. --Beman

4 4

[math_constants] Lots of "extra ';'" warnings
by sguazt 31 Jan '12

31 Jan '12

Hello, When compiling with GCC 4.6.2 with flags "-Wall -Wextra -ansi -pedantic", I get the following warnings: boost/math/constants/constants.hpp:211:199: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:212:200: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:213:204: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:214:205: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:215:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:216:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:217:205: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:218:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:219:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:220:206: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:221:207: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:222:211: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:223:197: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:224:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:225:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:226:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:227:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:228:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:229:212: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:230:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:231:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:232:214: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:233:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:234:207: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:235:206: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:236:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:237:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:238:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:239:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:240:214: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:241:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:242:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:243:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:244:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:245:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:246:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:247:196: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:248:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:249:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:250:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:251:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:252:210: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:253:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:254:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:255:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:256:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:257:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:258:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:259:198: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:260:201: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:261:209: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:262:200: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:263:208: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:264:204: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:265:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:266:205: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:267:202: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:268:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:269:203: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:270:217: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:271:212: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:272:212: warning: extra ‘;’ [-pedantic] boost/math/constants/constants.hpp:273:219: warning: extra ‘;’ [-pedantic] Could you fix them? Thank you very much, Best, -- Marco

1 0

[strings][unicode] Proposals for Improved String Interoperability in a Unicode World
by Beman Dawes 31 Jan '12

31 Jan '12

Beman.github.com/string-interoperability/interop_white_paper.html describes Boost components intended to ease string interoperability in general and Unicode string interoperability in particular. These proposals are the Boost version of the TR2 proposals made in N3336, Adapting Standard Library Strings and I/O to a Unicode World. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3336.html. I'm very interested in hearing comments about either the Boost or the TR2 proposal. Are these useful additions? Is there a better way to achieve the same easy interoperability goals? Where is the best home for the Boost proposals? A separate library? Part of some existing library? Are these proposals orthogonal to the need for deeper Unicode functionality, such as Mathias Gaunard's Unicode components? --Beman

7 27

[c++TR2] N3334, Proposing array_ref<T> and string_ref
by Beman Dawes 31 Jan '12

31 Jan '12

On Sat, Jan 28, 2012 at 8:12 PM, Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > On 01/28/2012 05:46 PM, Beman Dawes wrote: >> >> Beman.github.com/string-interoperability/interop_white_paper.html >> describes Boost components intended to ease string interoperability in >> general and Unicode string interoperability in particular. >> >> These proposals are the Boost version of the TR2 proposals made in >> N3336, Adapting Standard Library Strings and I/O to a Unicode World. >> See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3336.html. >> >> I'm very interested in hearing comments about either the Boost or the >> TR2 proposal. Are these useful additions? Is there a better way to >> achieve the same easy interoperability goals? > > > I think you should consider the points being made in N3334. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html While this proposal isn't from Boost, it impacts interests of Boost developers enough that I think it is worth discussing here as a separate topic. Mathias continues: > While that proposal is in my opinion not good enough, it raises an important > issue that is often present with std::string-based or similar designs. > > A function that takes a std::string, or a boost::filesystem::path for that > matter, necessarily causes the [caller] to copy the data into a heap-allocated > buffer, even if there is no need to. Some std library string implementations avoid the heap allocation for small strings, but still there is an unnecessary copy happening even in those implementations. Your point is well taken and I've often worried about it with boost::filesystem::path. > Use of the range concept would solve that issue, but then that requires > making the function a template. A type-erased range would be possible, but > that has significant performance overhead. > a string_ref or path_ref is maybe the lesser evil. One of my blink reactions is that array_ref<T> and basic_string_ref<charT, traits> are range generators and I was a bit surprised to see the implementation was a pointer and length rather than two pointers. Or better yet, two iterators or an explicit range component. With iterators, a basic_string_ref could do encoding conversions on-the-fly without need of temporary strings. But I have no idea if that is workable or actually is better. What do other Boosters think? --Beman --Beman

5 7

[conversion] Lot of 'long long' warnings
by sguazt 31 Jan '12

31 Jan '12

Hello, When compiling with GCC 4.6.2 with flags '-Wall -Wextra -ansi -pedantic', I get the following warnings concerning the use of the 'long long' type under the ISO C++98: boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:16:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:21:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:28:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:33:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:40:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:45:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:52:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:57:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:64:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:69:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:76:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:81:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:88:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:93:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:100:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:105:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:112:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:117:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:124:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:129:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:136:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:141:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:148:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:153:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:160:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:165:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:172:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:177:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:184:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:189:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:196:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:201:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:208:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:213:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:220:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:225:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:232:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:237:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:244:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:249:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:256:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:261:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:268:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:273:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:280:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:285:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:292:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:297:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:303:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:304:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:309:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:315:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:316:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:321:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:327:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:328:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:333:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:339:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:340:13: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] boost-trunk/boost/numeric/conversion/detail/preprocessed/numeric_cast_traits_long_long.hpp:345:23: warning: ISO C++ 1998 does not support 'long long' [-Wlong-long] Could you fix them? Thank you very much. Best, -- Marco

3 3

[context] Boost.Context library accepted
by Giovanni Piero Deretta 31 Jan '12

31 Jan '12

Hi All, The mini-review of the boost.context library from Oliver Kowalke ended two weeks ago. After a slow start, three reviews were eventually submitted, all positive. For a mini-review, I think this is enough and, as the review manager, I'm happy to announce that Boost.Context is accepted as an official boost library. Congratulations to Oliver for this achievement and thanks for submitting an useful library to Boost. Most of the review discussions were around the quality of the documentation and some misunderstanding of some details of the library. While the documentation has greatly improved since the first review, I think that it can be still improved. I encourage Oliver to seek the help of some native English speaker to help copy edit the docs. Finally I would like to thanks everybody that participated in the review discussions and in particular those that submitted reviews. regards, -- Giovanni Deretta,

2 1

Requesting a review of Metaparse
by Abel Sinkovics 31 Jan '12

31 Jan '12

Hi, I've created a version of Metaparse that depends on the Boost libraries only. I request this version of Metaparse be placed in the queue for formal review. The zipped source code can be found here: http://abel.web.elte.hu/metaparse/metaparse.zip The documentation can be found here: http://abel.web.elte.hu/metaparse/metaparse The library has been tested on the following compilers: - GCC 4.6 (with and without -std=c++0x) - GCC 3.4 - Clang 2.9 - Visual C++ 10 A quick summary: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Regards, Abel

7 16

My non-system GCC doesn't link programs under b2
by Daryle Walker 30 Jan '12

30 Jan '12

I'm still using my 2002 PowerPC/G4 Mac with Mac OS X 10.4 (Tiger). I loaded GCC 4.6 (with multiprocessor options) onto it with MacPorts. I have a "user-config.jam" in my home folder like: //===using xsltproc : /opt/local/bin/xsltproc ; using boostbook : /opt/local/share/xsl/docbook-xsl/ : /opt/local/share/xml/docbook/4.2 ; using doxygen ; using darwin ;using gcc : 4.6 : g++-mp-4.6 : <cxxflags>-std=c++0x <cxxflags>-pthread ;//=== I've tested GCC-4.6 (with C++11 active) with a "Hello World!" program, so I know it works with single-file programs. I wanted to test "base_from_member" (part of Boost.Utility) and it worked with the default "darwin" target. (I ran "b2" in "BOOST_ROOT/libs/utility/test".) However, running "b2 toolset=gcc-4.6" ended in errors like: //===common.mkdir ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6common.mkdir ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debuggcc.compile.c++ ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test.o../base_from_member_test.cpp: In constructor 'bad_class::bad_class()':../base_from_member_test.cpp:129:21: warning: 'bad_class::x_' will be initialized after [-Wreorder]../base_from_member_test.cpp:510:39: warning: base 'base_class' [-Wreorder]../base_from_member_test.cpp:507:1: warning: when initialized here [-Wreorder]gcc.link ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test/usr/bin/ld: unknown flag: --start-groupcollect2: ld returned 1 exit status "g++-mp-4.6" -o "../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test" -Wl,--start-group "../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g ...failed gcc.link ../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug/base_from_member_test......skipped <p../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug>base_from_member_test.run for lack of <p../../../bin.v2/libs/utility/test/base_from_member_test.test/gcc-4.6/debug>base_from_member_test......failed updating 20 targets......skipped 40 targets......updated 126 targets...//=== GCC-4.6 compiles each C++ file into an object file just fine. The problem happens when linking various object and library files into an executable; whichever linker gets called (the system linker?) chokes on a "--start-group" flag. When I first started writing this message, I thought the problem was GCC-4.6 being too new for the linker, but maybe we have to tweak something in our Jam files instead. (Could it be the fact I downloaded the multiprocessor variant of GCC-4.6?) BTW, how do I specify that I only want to try out the base_from_member test without trying to build all other tests in the directory? Daryle W.

4 4

[thread] Can't use boost/thread/mutex.hpp without boost_system
by Artyom Beilis 30 Jan '12

30 Jan '12

Hello, The Boost.Thread version in trunk does not allow to use simple mutex as it was possible before: #include <boost/thread/mutex.hpp> #include <iostream> int main() { boost::mutex l; { boost::unique_lock<boost::mutex> g(l); std::cout << "Test" << std::endl; } } Was working fine without linking with 1.48 and 1.46 but now it fails with current trunk version requiring dependency on Boost.System. It breaks some code and breaks at least Boost.Locale. Is this change intentional or a bug? If it is intentional I'd like to know to fix Boost.Locale if not then is it possible to fix it. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

9 30

Re: [boost] [Boost-users] numeric_cast_traits/cstdint: request for fix in boost1.49
by John Maddock 30 Jan '12

30 Jan '12

>Currently HPUX/acc compiler fails in boost 1.48, because boost::int8_t was >being interpreted as a char, This causes duplicate class definition >in the file >./boost/numeric/conversion/detail/preprocessed/numeric_cast_traits.hpp >and hence many of compiled boost libs fail. Thanks for raising this on the list, I just posted these comments to the Trac ticket: "IMO this is the wrong fix: our code should make no assumptions about the actual type of uintXX_t etc. IMO the preprocessed headers are just plain wrong - you can't mix concrete types (char short etc) with typedefs (intXX_t) because you're just asking for problems with duplicate specializations. It has to be all real types throughout. BTW in addition to the two platforms mentioned above, this is also broken for Sun on Linux. Reassigning to the person who made these changes..." Not sure if we can fix this for 1.49, but you're right, it is a high priority. Hopefully Brandon Kohn is reading this as he made those changes? John.

5 9

[Boost.Asio] Asio is using Boost.Chrono for 1.49?
by Christian Hägele 30 Jan '12

30 Jan '12

Hello, as I looked through the changes for Boost.Asio with boost 1.49 I noticed that it looks like Boost.Chrono's steady_clock is used for timers (when std::chrono is not available). First of all that very nice, because steady_clock is not affected by change of the system-time. However I think there is a major problem on windows. On windows there are some problems with QueryPerformancecoutner in multi-processor systems (http://support.microsoft.com/kb/274323) There is also a comment in boost/chrono/system_clocks.hpp about this issue and no real solution provided. Is that problem solved by now? If not will the better choice be to stick with the old system-time implementation until std::chrono is supported on MSVC? Or is this problem rather a minor problem and can be ignored? Regards, Christian

1 0

[bjam] copy a file
by lcaminiti 30 Jan '12

30 Jan '12

Hello all, I'd have a Jamfile that has a "doc" rule to build documentation `bjam doc`. I'd like to program another rule "config_doc" inside the Jamfile that does the following: bjam config_doc: 1) Copy the file /etc/config.txt to ./ 2) Copy the file ./src/config.txt to /etc/ 3) Run the doc rule 4) Copy the file ./config.txt into /etc/ Where ./ is the current directory from where I'm running bjam. Ideally, I'd like 4) to be executed even if 3) fails. Is there a way to do this? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-bjam-copy-a-file-tp4321537p4321537… Sent from the Boost - Dev mailing list archive at Nabble.com.

8 15

Latest Boost.Process ?
by Mathias Gaunard 29 Jan '12

29 Jan '12

I wanted to use Boost.Process, and the latest I could fine is from June at <https://github.com/JeffFlinn/boost-process>. Including the main file is enough to get lots of errors, and after fixing them (and there are quite a lot), it appears the functions from the documentation are not there (stdout_to etc.) Is there any recent usable version somewhere?

2 3

[1.49.0] Beta 1 available
by Beman Dawes 28 Jan '12

28 Jan '12

Boost release 1.49.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ This release contains a new library, Boost.Heap priority queues, and numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://beta.boost.org/users/news/version_1_49_0. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

[phoenix] msvc 8.0 errors
by Lorenzo Caminiti 27 Jan '12

27 Jan '12

Hello all, Why doesn't this Phoenix 3.0 code compile? (I'm sure, I'm doing something wrong... but I can't see what...) #include <boost/spirit/include/phoenix.hpp> #define BOOST_TEST_MODULE AddPhoenix #include <boost/test/unit_test.hpp> #include <algorithm> #include <iostream> BOOST_AUTO_TEST_CASE( add_phoenix ) //[add_phoenix { using boost::phoenix::let; using boost::phoenix::local_names::_f; using boost::phoenix::cref; using boost::phoenix::ref; using boost::phoenix::arg_names::_1; int sum = 0, factor = 10; int nums[] = {1, 2, 3}; // Passed to template, `factor` by constant, and defined in expression. std::for_each(nums, nums + 3, let(_f = cref(factor))[ // Unfortunately, body cannot use C++ statement syntax. ref(sum) += _f * _1 // Access `sum` by reference. ]); BOOST_CHECK( sum == 60 ); } //] On MSVC 8.0: ...patience... ...patience... ...found 3219 targets... ...updating 114 targets... compile-c-c++ bin\add_phoenix.test\msvc-8.0\debug\threading-multi\add_phoenix.obj add_phoenix.cpp C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2784: 'boost::phoenix::actor<as_composite<boost::phoenix::multiplies_eval,T0,boost::phoenix::actor<BaseT1>>::type> boost::phoenix::operator *(const T0 &,const boost::phoenix::actor<BaseT1> &)' : could not deduce template argument for 'const boost::phoenix::actor<BaseT1> &' from 'boost::mpl::void_' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(107) : see declaration of 'boost::phoenix::operator *' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::phoenix::result_of_multiplies<X,Y>' being compiled with [ X=const int &, Y=boost::mpl::void_ & ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(76) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled with [ C=boost::mpl::or_<boost::phoenix::is_actor<const int &>,boost::phoenix::is_actor<boost::mpl::void_ &>>, F1=boost::phoenix::re_curry<boost::phoenix::multiplies_eval,const int &,boost::mpl::void_ &>, F2=boost::phoenix::result_of_multiplies<const int &,boost::mpl::void_ &> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/detail/composite_eval.hpp(88) : see reference to class template instantiation 'boost::phoenix::multiplies_eval::result<Env,A0,A1>' being compiled with [ Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>>, A0=boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>, A1=boost::phoenix::argument<0> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/composite.hpp(60) : see reference to class template instantiation 'boost::phoenix::detail::composite_eval<2>::result<Composite,Env>' being compiled with [ Composite=boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>, Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(68) : see reference to class template instantiation 'boost::phoenix::composite<EvalPolicy,EvalTuple>::result<Env>' being compiled with [ EvalPolicy=boost::phoenix::multiplies_eval, EvalTuple=boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>, Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/detail/composite_eval.hpp(88) : see reference to class template instantiation 'boost::phoenix::plus_assign_eval::result<Env,A0,A1>' being compiled with [ Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>>, A0=boost::phoenix::reference<int>, A1=boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/composite.hpp(60) : see reference to class template instantiation 'boost::phoenix::detail::composite_eval<2>::result<Composite,Env>' being compiled with [ Composite=boost::phoenix::composite<boost::phoenix::plus_assign_eval,boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>, Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/scope/let.hpp(48) : see reference to class template instantiation 'boost::phoenix::composite<EvalPolicy,EvalTuple>::result<Env>' being compiled with [ EvalPolicy=boost::phoenix::plus_assign_eval, EvalTuple=boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>, Env=boost::phoenix::scoped_environment<boost::phoenix::basic_environment<>,boost::phoenix::basic_environment<>,boost::fusion::vector1<const int &>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/actor.hpp(56) : see reference to class template instantiation 'boost::phoenix::let_actor<Base,Vars,Map>::result<Env>' being compiled with [ Base=boost::phoenix::composite<boost::phoenix::plus_assign_eval,boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>, Vars=boost::fusion::vector<boost::phoenix::reference<const int>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>, Map=boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>, Env=boost::phoenix::basic_environment<> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::phoenix::eval_result<Eval,Env>' being compiled with [ Eval=boost::phoenix::let_actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval,boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::vector<boost::phoenix::reference<const int>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>>, Env=boost::phoenix::basic_environment<> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/core/actor.hpp(91) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled with [ C=boost::mpl::bool_<false>, F1=boost::mpl::identity<boost::phoenix::detail::error_expecting_arguments>, F2=boost::phoenix::eval_result<boost::phoenix::let_actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval,boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::vector<boost::phoenix::reference<const int>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>>,boost::phoenix::basic_environment<>> ] add_phoenix.cpp(29) : see reference to class template instantiation 'boost::phoenix::actor<Eval>' being compiled with [ Eval=boost::phoenix::let_actor<boost::phoenix::composite<boost::phoenix::plus_assign_eval,boost::fusion::vector<boost::phoenix::reference<int>,boost::phoenix::composite<boost::phoenix::multiplies_eval,boost::fusion::vector<boost::phoenix::local_variable<boost::phoenix::local_names::_f_key>,boost::phoenix::argument<0>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,boost::fusion::vector<boost::phoenix::reference<const int>,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>,boost::phoenix::detail::map_local_index_to_tuple<boost::phoenix::local_names::_f_key,boost::phoenix::detail::unused<1>,boost::phoenix::detail::unused<2>,boost::phoenix::detail::unused<3>,boost::phoenix::detail::unused<4>,boost::phoenix::detail::unused<5>,boost::phoenix::detail::unused<6>,boost::phoenix::detail::unused<7>,boost::phoenix::detail::unused<8>,boost::phoenix::detail::unused<9>>> ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2784: 'boost::phoenix::actor<as_composite<boost::phoenix::multiplies_eval,boost::phoenix::actor<Eval>,T1>::type> boost::phoenix::operator *(const boost::phoenix::actor<Eval> &,const T1 &)' : could not deduce template argument for 'const boost::phoenix::actor<Eval> &' from 'const int' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(107) : see declaration of 'boost::phoenix::operator *' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2784: 'boost::phoenix::actor<as_composite<boost::phoenix::multiplies_eval,boost::phoenix::actor<Eval>,boost::phoenix::actor<BaseT1>>::type> boost::phoenix::operator *(const boost::phoenix::actor<Eval> &,const boost::phoenix::actor<BaseT1> &)' : could not deduce template argument for 'const boost::phoenix::actor<Eval> &' from 'const int' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(107) : see declaration of 'boost::phoenix::operator *' C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2677: binary '*' : no global operator found which takes type 'boost::mpl::void_' (or there is no acceptable conversion) C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2866: 'boost::phoenix::result_of_multiplies<X,Y>::size' : a const static data member of a managed type must be initialized at the point of declaration with [ X=const int &, Y=boost::mpl::void_ & ] C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2057: expected constant expression C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/spirit/home/phoenix/operator/arithmetic.hpp(54) : error C2975: 'N' : invalid template argument for 'boost::mpl::at_c', expected compile-time constant expression C:\Users\lorcam\Desktop\code\boost\trunk.windows\boost/mpl/at.hpp(41) : see declaration of 'N' call "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"bin\add_phoenix.test\msvc-8.0\debug\threading-multi\add_phoenix.obj.rsp" ...failed compile-c-c++ bin\add_phoenix.test\msvc-8.0\debug\threading-multi\add_phoenix.obj... ...failed updating 1 target... Thanks a lot! --Lorenzo

1 0

multi_index problems
by brook＠biology.nmsu.edu 26 Jan '12

26 Jan '12

I am trying to use boost.MultiIndex as a class data member and am having difficulty because it seems that calling get<>() will not compile on a NetBSD box (gcc version 4.1.3). The code below illustrates a simple test case. Am I missing something obvious or doing something clearly mistaken? Any help is greatly appreciated. Thanks alot. Cheers, Brook =========================================================================== #include <boost/multi_index_container.hpp> #include <boost/multi_index/sequenced_index.hpp> namespace mi = boost::multi_index; template < typename T > struct container { typedef mi::multi_index_container< T, mi::indexed_by< mi::sequenced< > > > type; }; template < typename T > struct S { typedef typename container< T >::type container_type; void operator () () const { c_.get<0>(); // XXX - will not compile } private: container_type c_; }; int main () { return 0; }

2 1

[codecvt] UTF-8 codecvt
by Artyom Beilis 26 Jan '12

26 Jan '12

Hello, There is an implementation of UTF-8 codecvt facet for various purposes. Unfortunately it has two problems: 1. It does not implement UTF-16 properly (only UCS-2) 2. It requires linking with some library. Boost.Locale provides codecvt facets and I'm planning to add some template for codecvt converter in header files basically Boost.Locale will have header only version of utf-8 codecvt facet and actually very simple pattern to implement any codecvt facet for stateless encoding. I thought about two options: 1. Put it in boost::locale namespace as part of Boost.Locale library 2. Create some small "codecvt" boost library that would provide a simple framework for generation of codecvt facets for boost in general and it would include utf8 codecvt as well. Generally it would look like this: Converter concept: class Converter { public: // copyable Converter(Converter const &); // Max MB length for single Unicode code point int max_length() const; // convert a single mb sequence to code point // returing constants illegal or incomplete in case // if invalid sequence to incomplete sequence uint32_t to_unicode(char const *&begin,char const *end) const; // Convert codepoint u to [begin,end) returning mb length // or returning illegal if it is impossible to convert u to mb sequence // or U is invalid or incomplete if [begin,end) has not enough space uint32_t from_unicode(uint32_t u,char *begin,char const *end) const; }; Note, the converter works only for stateless encodings (which are 99% of all used encodings) And the basic facet would be defined as following: template<typename CharType,typename EncoderType,int size = sizeof(CharType)> class code_converter; Such that for converter concept utf8_converter I can create a utf8_codecvt facet as code_converter<wchar_t,utf8_converter> - is a facet that can be imbued to the locale object. The biggest "trick" is actually implementing codecvt facet to handle UTF-16 properly and it is implemented in Boost.Locale. So Boosters: Do You Want It Boost.Codecvt or it is fine to have it as part of Boost.Locale. In either case it would be header only "codecvt" framework. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

2 2

Scoped Enum Emulation
by Joshua Boyce 26 Jan '12

26 Jan '12

I'm currently updating some of my code to take advantage of C++0x features where available, but I also want to retain backwards compatibility with C++03. I was looking at scoped enums and noticed a thread on the mailing list by Beman Dawes discussing a scoped enum emulation implementation for Boost. I see that it's currently being used by Boost, and resides in /boost/detail/scoped_enum_emulation.hpp. My question is, why is this an implementation detail? Would it be possible for it to be moved to Boost.Config with the other 'helper' macros like BOOST_CONSTEXPR? Obviously it's not hard to reimplement, but I figured that it would be useful to other library users, so it would be best (imo) if it were moved somewhere public, rather than being hidden away. Thanks.

4 10

Re: [boost] [lexical_cast] Fast conversion from boost::iterator_range<std::string::iterator>?
by Matthew Chambers 26 Jan '12

26 Jan '12

On Oct 13, 2011 Michel Morin wrote: > lexical_cast made optimizations for some types (such as `std::string`) > to achieve better performance. But, from my experience, > it seems that lexical_cast does not make any optimization for > `boost::iterator_range<std::string::iterator>`. > > Is there any plan to add optimization for such iterator ranges? > Currently, > - `lexical_cast<int>(std::string(iter_rng.begin(), iter_rng.end()))` > is faster > than `lexical_cast<int>(iter_rng)`. > - Assuming it is safe to use `std::atoi`, > `std::atoi(&iter_rng.front())` is faster > than both of the above two methods. > (`iter_rng` is an instance of `boost::iterator_range<std::string::iterator>`.) > > Regards, > Michel This post was on the boost users list but never got a reply. I figure it might be a better fit on the developer list. I too would like to see optimized conversions work on string ranges; what's the point in doing a fast conversion if you have to do a string copy first? :) -Matt

8 16

Attribute names with underscores for GCC
by Michel Morin 26 Jan '12

26 Jan '12

Recently, Petr Machata created several trac tickets for requesting the use of attribute names with underscores for GCC. Since there is no link to the GCC's documentation in the tickets, I'd like to put a link to the documentation. In the GCC's manuals --> "Extensions to the C Language Family" --> "Declaring Attributes of Functions", "Specifying Attributes of Variables", and "Specifying Attributes of Types", there is description about attributes with preceding and following `__`: You may also specify attributes with `__' preceding and following each keyword. This allows you to use them in header files without being concerned about a possible macro of the same name. For example, you may use __noreturn__ instead of noreturn. Here are links to the gcc-2.9.5's documentation: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC84 http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC90 http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC91 I also checked manuals of gcc-3.0.4 and 4.0.4, and found the same description. Hope this helps, Michel

2 2

[assert] [exception] Fast output binary file size growth
by Antony Polukhin 26 Jan '12

26 Jan '12

Greetings, When BOOST_ENABLE_ASSERT_HANDLER is defined or BOOST_THROW_EXCEPTION used, compiler generates a string with function name. If a function is templated, compiler will generate a string for each function template. That leads to a huge binary files. Consider the following example: #define BOOST_ENABLE_ASSERT_HANDLER #include <boost/assert.hpp> template <class MplVectorT> void do_something(bool v) { BOOST_ASSERT(v); } void do_something<boost::mpl::vector<int, double>>(v); void do_something<boost::mpl::vector<int, int>>(v); This two functions will generate strings like "void do_something<MplVectorT>(bool v) [with MplVectorT = boost::mpl::vector<int, double> ]" and "void do_something<MplVectorT>(bool v) [with MplVectorT = boost::mpl::vector<int, int> ]". When there is more mataprogramming, one such string can have a size of a few kilobytes. In one of my binaries, such strings take more than 50 megabytes of binary size (total size of binary is 70 megabytes). I`ve got a patch and documentation update for Boost.Assert and Boost.Exception, that allow to disable construction of such strings or to use different macro for current function name (for example macro that prints ONLY function name). Is there interest in this feature/patches? Best regards, Antony Polukhin

2 2

[filesystem] noexcept question? [was: Scoped Enum Emulation]
by Beman Dawes 26 Jan '12

26 Jan '12

On Tue, Jan 24, 2012 at 8:38 PM, Joshua Boyce <raptorfactor(a)raptorfactor.com> wrote: > While I've got your attention, I have a similar question along the same > lines. I notice in the mailing list archives that you added some noexcept > related macros to Boost.Config on trunk back in October 2011, I can't see > them in the current trunk or release though. What happened to those? They won't go in 1.49.0, but will begin to go into trunk within the next month. Likewise some other C++11 support, such as rvalue reference signatures. --Beman

2 1

[filesystem] documentation typo
by Greg Rubino 26 Jan '12

26 Jan '12

Hello, It looks like there's some copy/paste residue in http://www.boost.org/doc/libs/1_48_0/libs/filesystem/v3/doc/reference.html#… basic_filesystem_error has become filesystem_error, but in the anchor it's still called 'basic_filesystem_error', and also there are a couple of references on the page to basic_filesystem_error. This momentarily confused me when I was moving a codebase from v1 to v3 yesterday, so I thought it was worth mentioning. I've entered a trac ticket for this issue: https://svn.boost.org/trac/boost/ticket/6448 but I would be delighted to submit a patch for this since I've been wanting to get more involved in Boost, but it would be my first time doing and I'm not quite sure how to go about it. I assume that it involves checking out the trunk and modifying the necessary files, but I'm not sure after that. Greg

2 1

Boost.Application
by Renato Tegon Forti 26 Jan '12

26 Jan '12

Hi All, I have the first prototype of the "Boost.Application" ready! I would like to receive comments so I can refine the library. Please send your feedback to re.tf(a)acm.org 0) Introduction A Boost.Application allows a developer run your application as a Windows service, as a Unix/Linux daemon, or as a usual interactive application (terminal) without the need to add extra code, the library abstract OS specific API and provide a ease common interface. In case of server application, developer need only compile your code on a Windows to have a ready to play Windows Service or in a UNIX/Linux to have Daemon. CTRL-C signals and SCM (Service Control Manager) controls handlers are available for terminating, pause/resume(windows) the application constructively and many other until methods are available in application class like a single instance running limitation! 1) Download: https://sourceforge.net/projects/boostapp/ 2) Installation: The library is one: Automatic linking You should unpack the files and copy: Boost.Application_pre_alpha_1\boost\application To: boost_1_48_0\boost and, Boost.Application_pre_alpha_1\libs\application To: boost_1_48_0\libs 3) Build Then you must build, for example (in windows): bjam toolset=msvc-9.0 variant=debug threading=multi link=shared define=_BIND_TO_CURRENT_VCLIBS_VERSION 4) Documentation The project has an incomplete documentation: Boost.Application_pre_alpha_1\libs\application\doc\html\index.html 5) Use however, the tutorial explains how to use the lib, and that generally goes like this: ---------------------------------------------------------------------------- -------------------- #include <boost/application/engine.hpp> class myapp : public boost::application::application { protected: int main(const std::vector<std::string>& args) { // your application logic here! while(1) { std::cout << "Hello Boost.Application!" << std::endl; // ... if(state() == boost::application::application_stoped) { break; } } return 0; } }; BOOST_APP(myapp, "MainTutorial1", "Boost.Application Main Tutorial 1!", boost::application::default_application_type, 1, 0, 1) ---------------------------------------------------------------------------- -------------------- The folder: Boost.Application_pre_alpha_1\libs\application\example\tutorial Has all tutorial files! I tested the lib on Windows VC9 (Windows Service) and Ubuntu 11 GCC 4 (Daemon)! 6) Questions: * Is there any interest in this library? * If Yes! What are the refinements? (see todo, for some) Please send your feedback to re.tf(a)acm.org Thanks to all Renato

3 5

Boost.Application (PART II)
by Renato Tegon Forti 26 Jan '12

26 Jan '12

Hi all, I want to emphasize: 1) This is a prototype, a starting point to find out if this is an interesting lib to boost! 2) And if 1 is true! I will compile all comments and make modifications to meet "boost"! My doubt is if this lib don't violate: "The library must be generally useful and not restricted to a narrow problem domain." About comments of friends! First, thank you for the comments! They always show a new way of doing things, which I had not thought of! This is the main reason I'm doing (trying to) this lib, to have the opportunity to learn (and contribute) with you! I will try to enumerate the comments, and then build a path to follow for next version (if [1] is satisfied. Do you think I need more votes to continue the effort?) a) >>So selling it as "ready to play" UNIX/Linux daemon is a bit - erm - exaggerating. Sorry about this, I will change this description! I agree with you! Sorry! b) >> Why is the application not a functor or even a function? . Again I agree with you! This is a better way!, for sample I can handle exception in my main too! Thanks about this suggestion! >> I don't like it, though I don't have an alternative solution at hand. Somehow this feels very clumsy with that init() method. As example of a pure OO approach you could have a look at Qts QApplication. I will look QApplication! If you have time! You could describe what you think would be the right path follows in more detail, I appreciate it! c) >> The biggest concern for me is that you're using narrow strings I will provide wide strings. I don't know how yet. I will check Boost.Filesystem! Besides, there is other example to follow? For sample, I need use W version (GetModuleFileNameW) on all? And use a function like this to convert: inline void convert(const char* from, std::wstring & to, const codecvt_type& cvt) D) Other question, to handle exceptions! Any Idea? e) "Install and uninstall windows service" functionality, be a part of the application instead of a separate one and using a callback. f) * In the unknown mode, the program can run in either mode provided someone puts something in the command line. Could that rather be a callback maybe post initialize such that we tell your application which one we want. This way the developer controls his command line. After all, it might not come from the command line but instead from a configuration file. -------------------------------------------------------------------------- What else? Thanks for help!!!

1 0

boost filesystem path as utf-8?
by Emil Dotchevski 25 Jan '12

25 Jan '12

Hello, I understand that the path class .native() member function's return type differs depending on the platform (wstring on windows, for example.) Is there a way to get the path as a utf-8 string regardless of the platform? Likewise, is there a way to construct a path object from a utf-8 string regardless of the platform? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 9

[log][phoenix] Questions on porting to phoenix
by Andrey Semashev 25 Jan '12

25 Jan '12

Hi, [My apologies for the long post] I'm trying to port filters and formatters of Boost.Log to Boost.Phoenix and I'm not sure I understand what's the best way to go. Hope someone can help me out. A short introduction of the terms and what is currently available. * An attribute value is a type-erased value, something similar to boost::any but with more advanced interface to allow visitation and extraction of the stored value. * A log record is an object which contains a set of named attribute values. For simplicity, let's say: class attribute_value; typedef map< string, attribute_value > attribute_values_view; class record { public: attribute_values_view const& attribute_values() const; string const& message() const; }; * A filter is a function that accepts attribute values and returns a bool: typedef function< bool (attribute_values_view const&) > filter; The filter is assumed to pass the log record if it returns true. * A formatter is a function that accepts a log record and a stream and outputs strings or attribute values to the stream: typedef function< void (ostream&, record const&) > formatter; * I already have the code that extracts attribute values from log records. What I'm trying to achieve is something along these lines (this is not a finalized interface yet): enum my_severity { info, warning, error }; BOOST_LOG_REGISTER_ATTRIBUTE("Severity", severity, my_severity) filter flt = severity >= warning; formatter fmt = stream << "[" << severity << "] " << message; Here, "stream" and "message" are keywords provided by Boost.Log, the former is a placeholder for the stream argument of the formatter function, and the latter returns the result of the record::message() method. Now, the BOOST_LOG_REGISTER_ATTRIBUTE macro is what I'm struggling on. It should create a new keyword (severity) which should: 1. Be a POD object to be statically initialized. 2. Contain the information on the type (my_severity) and name ("Severity") of the attribute to be able to extract it from the log record. 3. Be a Phoenix object to initiate lazy expression generation. >From what I gathered from the docs and examples, the generated keyword should be a terminal, in terms of Proto. Am I correct? In order to produce the value, during the evaluation the keyword should receive either a log record or a attribute_values_view and I can't quite understand how do I do that. Basically, I don't quite understand how do I declare and implement a terminal so that it works with Phoenix. This question also applies to the "stream" and "message" keywords but I suspect the solution will be similar. Maybe there is an example of doing this in the docs or elsewhere. I'll be glad if someone provides a link or example of doing this. Thanks in advance.

5 11

[quickboost] single HTML page?
by lcaminiti 24 Jan '12

24 Jan '12

Hello all, Is there a way to have quickbook generate a single HTML page? (Maybe some XSL param...) Right now, different sections appear on different HTML pages. But for a very simple doc, I only have 3 short sections and it'd make more sense for them to be displayed on a single page while still remain separate section and appear separately in the table of context. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-quickboost-single-HTML-page-tp4323… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

Bug reports - Showstoppers and Regressions
by Marshall Clow 24 Jan '12

24 Jan '12

There are a couple of useful reports on svn.boost.org: Active Showstoppers: https://svn.boost.org/trac/boost/report/43 Active Regressions: https://svn.boost.org/trac/boost/report/30 To shortcut part of the discussion, here are some definitions (taken from https://svn.boost.org/trac/boost/wiki/TicketWorkflow) • Showstopper - this problem is so bad, that we should hold up a release if it's not fixed. Note that the release managers and/or the library maintainers may have different opinions. • Regression - something used to work (in a previous release), but no longer does. IMHO, these bugs should be at least looked at before each release. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

8 15

[BGL] Any interest in updated maximum adjacency search?
by Fernando Vilas 23 Jan '12

23 Jan '12

Hi, As a part of my graduate research, I have been using the maximum adjacency search algorithm. In the BGL, it is implemented in the stoer_wagner_min_cut functions. I have already broken it out of there, to be a search with a visitor, like BFS. I also implemented a dummy visitor and wrote visitors for my research. It would be very easy to implement a min-cut visitor so that the Stoer-Wagner functionality is maintained without a public API change. As a contributor in other FLOSS projects, I would like to contribute this code back to the Boost library, under the Boost license, if there is interest in the code. That said, this will be my first contribution to Boost, so I would most likely need someone willing to help me navigate the approval process and let me know where the code needs to be improved to meet the normally high standards on this project. -- Thanks, Fernando Vilas fvilas(a)iname.com

2 2

[quickbook] email tag?
by lcaminiti 21 Jan '12

21 Jan '12

Hello all, Is there a preferred way or special tag to specify the author's email within the [library ...] tag? [library Boost.LocalFunction [author [Caminiti, Lorenzo]] ... ] Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-quickbook-email-tag-tp4310264p4310… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 4

[local] name (was Re: "protected" APIs)
by Lorenzo Caminiti 21 Jan '12

21 Jan '12

On Mon, Jan 16, 2012 at 6:06 AM, Thomas Klimpel <Thomas.Klimpel(a)synopsys.com> wrote: > Hartmut Kaiser wrote: >> > On 01/02/2012 10:25 AM, Lorenzo Caminiti wrote: >> > > Hello all, >> > > >> > > Boost.Closure (formerly, Boost.Local) needs to use some macros, >> types, >> > > etc that are currently marked private in Boost.ScopeExit: >> > >> > Boost.Closure? I really don't like that name is at implies functional >> > programming capabilities. Didn't you decide to name it >> Boost.LocalFunction >> > instead? >> >> I second that concern. I wouldn't like for the local function library >> to >> claim the name 'closure'. >> This would be >> >> a) totally misleading and >> b) inhibits to give that name to a potential real closure library in >> the >> future. > > +1 As I said before, I'm equally happy with Boost.LocalFunction and Boost.Closure. I'm checking with my review manager about going back from Closure to LocalFunction given that a few people have now expressed such a preference. I'll keep everyone posted :) > Or more precisely, just ignoring mails questioning the name Boost.Closure is not good style. In a functional programming language, many things can be done with a closure (for example returning it from a function), and it is unclear to me, whether Boost.Local really is able to approximate this functionality in a sufficiently usable way. It might be true, but then please point me to the corresponding passage in the documentation. Boost.Local docs do not (yet) explain how and when local functions can be returned because that was a homework from the review. I'm pasting below a few examples that I will include in the docs: //[test_return_inc_cpp #include <boost/closure.hpp> #include <boost/function.hpp> #define BOOST_TEST_MODULE ReturnInc #include <boost/test/unit_test.hpp> boost::function<int (void)> inc(int& value) { int BOOST_CLOSURE(bind& value) { return ++value; } BOOST_CLOSURE_END(i) return i; } BOOST_AUTO_TEST_CASE( return_inc ) { int value1 = 0; // Reference valid in scope where closure is used. boost::function<int (void)> inc1 = inc(value1); int value2 = 0; boost::function<int (void)> inc2 = inc(value2); BOOST_CHECK( inc1() == 1 ); BOOST_CHECK( inc1() == 2 ); BOOST_CHECK( inc2() == 1 ); BOOST_CHECK( inc1() == 3 ); } //] //[test_return_setget_cpp #include <boost/closure.hpp> #include <boost/function.hpp> #define BOOST_TEST_MODULE ReturnSetGet #include <boost/test/unit_test.hpp> #include <string> boost::function<void (std::string const&)> set; boost::function<std::string const& (void)> get; void action(void) { // State `message` hidden behind access functions from here. BOOST_CHECK( get() == "abc" ); set("xyz"); BOOST_CHECK( get() == "xyz" ); } BOOST_AUTO_TEST_CASE( return_setget ) { std::string message = "abc"; // Reference valid where closure used. void BOOST_CLOSURE(bind& message, std::string const& text) { message = text; } BOOST_CLOSURE_END(s) set = s; std::string const& BOOST_CLOSURE(const bind& message) { return message; } BOOST_CLOSURE_END(g) get = g; action(); } //] //[test_return_derivative_cpp #include <boost/closure.hpp> #include <boost/function.hpp> #define BOOST_TEST_MODULE ReturnDerivative #include <boost/test/unit_test.hpp> boost::function<int (int)> derivative(boost::function<int (int)>& f, int dx) { int BOOST_CLOSURE(bind& f, const bind dx, int x) { return (f(x + dx) - f(x)) / dx; } BOOST_CLOSURE_END(deriv) return deriv; } BOOST_AUTO_TEST_CASE( return_derivative ) { int BOOST_CLOSURE(int x) { return x + 4; } BOOST_CLOSURE_END(add2) boost::function<int (int)> a2 = add2; // Reference valid where closure used. boost::function<int (int)> d2 = derivative(a2, 2); BOOST_CHECK( d2(6) == 1 ); } //] //[test_return_this_cpp #include <boost/closure.hpp> #include <boost/function.hpp> #define BOOST_TEST_MODULE ReturnThis #include <boost/test/unit_test.hpp> struct number { number(int value) : value_(value) {} boost::function<int (void)> inc(void) { int BOOST_CLOSURE(bind this_) { return ++this_->value_; } BOOST_CLOSURE_END(i) return i; } private: int value_; }; BOOST_AUTO_TEST_CASE( return_this ) { number n1 = 0; // Object valid in scope where closure is used. boost::function<int (void)> inc1 = n1.inc(); number n2 = 0; boost::function<int (void)> inc2 = n2.inc(); BOOST_CHECK( inc1() == 1 ); BOOST_CHECK( inc1() == 2 ); BOOST_CHECK( inc2() == 1 ); BOOST_CHECK( inc1() == 3 ); } //] Thanks. --Lorenzo

3 2

[quickbook] changing paths
by lcaminiti 21 Jan '12

21 Jan '12

Hello all, How can I change the paths were Boost.QuickBook looks for the following files? 1) CSS and icon images by default from BOOST_ROOT/doc. 2) Navigation bar by default from BOOST_ROOT/tools/boostbook/xls. Essentially, I'd like to put the CSS, icon images, and navbar into a different path. Also, I'd like to change the navbar to one of my own. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-quickbook-changing-paths-tp3925967… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 4

[review] WANTED: Review Managers
by Ronald Garcia 20 Jan '12

20 Jan '12

Hi all, Currently the Boost review schedule has 8 libraries ready for review, but we need some individuals to volunteer to be review managers so that we can schedule reviews for them. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. The libraries on the review schedule are as follows (the "(M)" simply means that a manager is needed): * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Predef (M) If you are interested, able, and qualified to be a review manager for one of these libraries, please contact myself and/or John Phillips. Thank you. Best, Ron

1 0

[move] error: duplicate 'inline'
by Vicente J. Botet Escriba 19 Jan '12

19 Jan '12

Le 16/01/12 20:48, Beman Dawes a écrit : > On Mon, Jan 16, 2012 at 1:38 PM, Vicente J. Botet Escriba > <vicente.botet(a)wanadoo.fr> wrote: >> Le 16/01/12 19:30, Vicente J. Botet Escriba a écrit : >> >> Hi there is a minor Bug on trunk regression test for Boost.Move and all the >> libraries using it. >> >> Test output: Sandia-darwin-4.4_0x - move - back_move_inserter / >> darwin-4.4_0x >> Rev 76539 / Mon, 16 Jan 2012 11:49:32 +0000 >> Report Time: Mon, 16 Jan 2012 16:05:03 +0000 >> Compile [2012-01-16 12:32:57 UTC]: fail >> >> "/opt/local/bin/g++-mp-4.4" -ftemplate-depth-128 -std=gnu++0x -O0 >> -fno-inline -Wall -g -gdwarf-2 -fexceptions -DBOOST_ALL_NO_LIB=1 -I".." -c >> -o >> "/Volumes/scratch/kbelco/boost/results/boost/bin.v2/libs/move/test/back_move_inserter.test/darwin-4.4_0x/debug/link-static/back_move_inserter.o" >> "../libs/move/test/back_move_inserter.cpp" >> >> In file included from ../libs/move/test/back_move_inserter.cpp:11: >> ../boost/move/move.hpp:486: error: duplicate 'inline' >> ../boost/move/move.hpp:522: error: duplicate 'inline' >> >> >> Could this be fixed quickly? >> >> >> It seems that the problem has been merged to the release branch also. > Shouldn't this be posted on the main list? Maintainers don't > necessarily read the testing list. > > > Ion, could you analyze this blocking issue? Vicente

4 3

Permission to merge to release a remove-warnings-update
by Barend Gehrels 19 Jan '12

19 Jan '12

Hi, Christophe sent me this week a patch to avoid many warnings about unused parameters in many files. I applied that (all but one file which was not about unused parameters) and fixed some more. So this is a low-risk update which might be convenient for many users. All tests run fine. Do I have permission to still merge this with the Release branch? Thanks, Barend

1 0

Vote Boost Up for SourceForge Project of the Month
by Dave Abrahams 19 Jan '12

19 Jan '12

Folks, I was just informed that Boost is a top contender for SourceForge's February Project Of The Month. The vote is happening on TwtPoll, here: http://twtpoll.com/7vt4lq It's pretty close, so if you could vote Boost up, it could be good for our profile and our future. Thanks! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

9 8

boost log project - compile with mingw (gcc 4.5.4) on win7- problems
by Aleksander Sandro GRM 19 Jan '12

19 Jan '12

Dear, recently I started to use boost::log api. I work on win7 machine and use mingw-x86-64 compiler ver. 4.5.4. Now I got trunk version for boost and boost::log api and encountered problems with compilation. Problem is with: C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk>bjam --with-log -a toolset=gcc target-os=windows variant=release link=shared runtime-link=sha red define=BOOST_ALL_DYN_LINK define=BOOST_LOG_USE_CHAR stage C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\generators.jam:1085: in ensure-type from module generators error: target { simple_event_log.mc. } has no type C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\generators.jam:1319: in generators.construct from module generators C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1495: in construct from module object(typed-target)@354 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1298: in object(typed-target)(a)354.generate from module objec t(typed-target)@354 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@834 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)834.generate from module object( main-target)@834 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:258: in object(project-target)(a)343.generate from module obje ct(project-target)@343 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:848: in targets.generate-from-reference from module targets C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1217: in generate-dependencies from module object(install-ta rget-class)@97 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1269: in object(install-target-class)(a)97.generate from modul e object(install-target-class)@97 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@808 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)808.generate from module object( main-target)@808 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:848: in targets.generate-from-reference from module targets C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1217: in generate-dependencies from module object(top-level- target)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:1269: in alias-target-class.generate from module object(top- level-target)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk\boostcpp.jam:409: in build-multiple from module object(top-level-target)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk\boostcpp.jam:373: in object(top-level-target)(a)106.generate from module object(top-level-targe t)@106 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@812 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)812.generate from module object( main-target)@812 C:/Users/sandro/Documents/progs/opt/cpp_libs/boost_trunk/tools/build/v2\build-system.jam:736: in load from module build-system C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk\tools\build\v2/kernel\modules.jam:283: in import from module modules C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk\tools\build\v2/kernel/bootstrap.jam:142: in boost-build from module C:\Users\sandro\Documents\progs\opt\cpp_libs\boost_trunk\boost-build.jam:17: in module scope from module To correct the error in the spirit of link ...( unfortunately I can't find it now ) 1. boost_trunk\tools\build\v2\tools\mc.jam: line 41: actions compile { # mc $(MCFLAGS) -h "$(<[1]:DW)" -r "$(<[2]:DW)" "$(>:W)" # --- replace mc with windmc --- windmc $(MCFLAGS) -h "$(<[1]:DW)" -r "$(<[2]:DW)" "$(>:W)" } 2. boost_trunk\tools\build\v2\tools\gcc.jam: line 28: addin additional import import fortran ; import mc ; After compile starts but got errors in compile time. All compile message is attached in compile.log I use trunk versions from date 18.01.2012 for both, boost and boost::log api. Best regards, Sandro.

1 0

Re: [boost] [thread] Boost.Thread defines boost::move which conflicts with Boost.Move
by Evan Wallace 18 Jan '12

18 Jan '12

On Thu, 05 Jan 2012 07:00:27 +0100, Vicente J. Botet Escriba wrote:>Mankarse please, could you post here the patch for the boost.thread >class so that I can start the integration of what you have already done? I have attached a patch to the ticket (https://svn.boost.org/trac/boost/ticket/6194) This patch is fairly comprehensive in terms of code, but it does not include any tests or documentation. In the course of writing the patch, I created some simple tests, but I have not yet translated these into Boost.Test testcases, or included them in the patch. I have tested the basic functionality on a number of compilers, but there are probably still some bugs in the patched code. The patch contains a number of known problems that may be worth discussing:1) Explicit move() and copy() calls:boost::thread and boost::packaged_task both have templated constructors that take an rvalue reference to a functor (which they move or copy as appropriate). Templates parameters cannot be deduced to a type that is only reachable through an conversion operator. Template constructors can also never be explicitly instansiated. (As far as I know.) This means that the overloads that are used in the definitions of BOOST_COPYABLE_AND_MOVABLE types (BOOST_RV_REF(type), BOOST_CATCH_CONST_RLVALUE(type), type&), are not matched for rvalue objects (in C++03 mode). Example: //In C++11 the `CopyableAndMovableFunctor` would be //moved into the thread. //In C++03 this does not compile. boost::thread((CopyableAndMovableFunctor())) Here, no overload would be matched, because the `type` in the overloads is templated. To solve this problem I modified Boost.Move to add two member functions - `copy()` and `move()` - which forward to the rv const& and rv& conversion operators. With these, the above example can be rewritten as: //In both C++11 and C++03 the `CopyableAndMovableFunctor` //will be moved or copied into the thread as appropriate. boost::thread(CopyableAndMovableFunctor().move()), boost::thread(CopyableAndMovableFunctor().copy()) I can imagine the names `copy` and `move` being quite common, so this might cause unfortunate conflicts. Is this an acceptable change to Boost.Move? Is there another way to get the functionality that does not require this? 2) SFINAE requiredBoost.Move requires SFINAE, and by extension Boost.Thread now also requires SFINAE. Previously, Boost.Thread did not require SFINAE. Is this an acceptable regression, or should more work be put into maintaining compatibility with compilers that do not support SFINAE? 3) Not using has_move_emulation_enabledI did not notice the `has_move_emulation_enabled` metafunction, and instead used `is_convertible!(T&, boost::rv!(T))`. This may mean that some situations that `has_move_emulation_enabled` accounts for will not be accounted for by the code in the patch. I have not yet evaluated whether simply replacing all the occurrences will work. Any thoughts? 4) Not using Vicente's patches for #6174 or #5990By the time that I was aware of these patches, I had already independently fixed the issues. I have not looked at either patch in detail, but they each go about fixing the issues in a significantly different way from my patch. Which code should be used in each of these cases? Where should I go from here? I could do the integration into the svn trunk version, write the documentation, or update the tests to the new version. Are there any other tasks that I can help out with? I will of course keep the patch updated with fixes for any bugs that I find in it. Evan Wallace

5 11

[preprocessor] Warning: Incoming
by Paul Mensonides 18 Jan '12

18 Jan '12

I'm about to commit a relatively significant changeset to the pp-lib. This is the result of work by Edward Diener and I to add limited variadic support to the pp-lib. Edward can comment in more detail regarding the extent of those changes, but they do not add ground-up support. However, there are significant changes to heavily used low-level facilities such as BOOST_PP_TUPLE_ELEM (sometimes even complete implementation replacements). We have put in a great deal of effort to avoid introducing new errors or warnings in either the building of the Boost binaries or in the regression tests. However, we may have missed some issues. Regards, Paul Mensonides

11 42

[preprocessor] [variadic] BOOST_PP_VARIADICS vs BOOST_NO_VARIADIC_MACROS
by lcaminiti 18 Jan '12

18 Jan '12

Hello all, Why does Boost.Preprocessor redefines BOOST_PP_VARIAIDCS instead of just using BOOST_NO_VARIADIC_MACROS from Boost.Config? Furthermore, GCC supports variadics also when C++11 extensions are not enabled so I think the following should not && __GXX_EXPERIMENTAL_CXX0X__: // File: boost/preprocessor/config/config.hpp # /* Wave (C/C++), GCC (C++) */ # elif defined __WAVE__ && __WAVE_HAS_VARIADICS__ || defined __GNUC__ && __GXX_EXPERIMENTAL_CXX0X__ # define BOOST_PP_VARIADICS 1 Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-variadic-BOOST-PP-VAR… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

Need some 64-bit testing help.
by John Maddock 18 Jan '12

18 Jan '12

Folks, I need some help with the tests in: sandbox/big_number/libs/multiprecision/test Which I have an suspicion may have problems in 64-bit release mode (though I hope not!), so I'm looking for some folks to do a: bjam release --disable-concepts in that directory with whatever 64-bit compilers you have access to. Many thanks in advance! John.

4 8

Request for Interest in several Modules
by Artyom Beilis 18 Jan '12

18 Jan '12

Hello, I have several modules/libraries I developed and released under Boost License. - CppDB Sql Connectivity - Stack Trace - Shared Object Loading - Nowide UTF-8 friendly standard C/C++ library API. ---------------------------------- Let's start Boost.CppDB CppDB library: Sql Connectivity library currently not Boostified, released and actively maintained. http://cppcms.sourceforge.net/sql/cppdb/index.html How much interest in this library as-is with small obvious modifications like using Boost Namespace Boost.SharedObject: Simple Shared Object class for loading DLLs/SO - i.e. cross platfrom dlopen/dlclose + naming (libfoo.3.dylib/libfoo.so.3/foo-3.dll) http://cppcms.sourceforge.net/cppcms_ref_v0_99/classbooster_1_1shared__obje… Any interest in this simple class? Boost.StackTrace Collecting stack trace automatically from exception and printing it. Very Very useful for debugging. http://cppcms.sourceforge.net/cppcms_ref_v0_99/namespacebooster_1_1stack__t… http://cppcms.sourceforge.net/cppcms_ref_v0_99/backtrace_8h_source.html Any interest in this library. It works (collects a trace and prints it) on: Windows, Solaris, Linux, Mac OS X Boost.NoWide Standard C and C++ library UTF-8 friendly API for windows classes/functions: boost { nowide { [of]stream - iostreams with UTF-8 file names f(re)open - FILE * functions with UTF-8 file names remove, rename- UTF-8 parameters getenv,putenv - UTF-8 environment variables args - UTF-8 argc, argv } } Under non windows just (using std::...) These functions (like Boost.Locale) all are parts of CppCMS C++ Web framework. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

17 43

[build] How to build a multi version non-header-library
by Vicente J. Botet Escriba 18 Jan '12

18 Jan '12

Hi, I want to provide two versions for Boost.Thread, one using Boost.Chrono and the other not. Boost.Thread is a non-header-only library so I guess that I need to build two libraries with different names. Is there already a library in Boost in the same context on which I can base my build design? What is the simples way to do this with Boost.build? Any pointers to the doc? Thanks in advance, Vicente

2 2

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 18 Jan '12

18 Jan '12

Hi, Sorry for the late reply. On 1/10/2012 11:01 AM, Topher Cooper wrote: > > On 1/10/2012 1:37 AM, Adrian Michel wrote: >> The way I see it, the only common point between different optimization >> algorithms (if they are generic enough) is the objective function, >> which should have a very simple prototype: >> >> double f( std::vector< double> ); >> >> so in theory if different algorithms are implemented to accept the >> same types (in C++ sense) of objective functions, then you could run >> them interchangeably between GA, DE etc without any modification to >> the function or algorithm. > > That ignores multi-objective optimization. In that case the return type > would be, at a minimum std:vector<double>, and might require information > on what characteristics are maximized. > ... > The points you raised make sense, but I think they go beyond the intended scope of this initial release. Unlike many other boost libraries whose main purpose is to enhance the language, DE is intended almost exclusively for solving domain specific problems. Because DE can be applied in many areas, by developers with a variety of requirements and levels of knowledge, I believe taking an iterative approach based on users' feedback will increase the chances of creating a library that's useful in solving real problems. As I mentioned before, this is an initial implementation. Some of the features I intend to add in a later release are: - multi-objective optimization - constraint functions (as opposed to just plain boundary constraints) - design centering ("Design centering is a constraint satisfaction problem whose goal is to find the solution, which, when perturbed, remains feasible more often than any other solution") and others. But these features are not trivial, and it would help me to get a sense of how the library is used before I start working on them. So far, I have received several good suggestions, I would like to nail down a list of specific additional requirements that this library needs to meet before moving on to the next step (and I'm not sure what that may be). Please let me know how to proceed. Adrian www.tradery.com

1 0

Re: [boost] Proposal for a Differential Evolution C++library
by Adrian Michel 18 Jan '12

18 Jan '12

On 1/10/2012 1:32 AM, Graham, Jeff wrote: > > I can help test on i686, amd64 and arm9 running linux. > Great, thanks! Can you please download the library from http://www.amichel.com/de/de.zip and try to build it? Let me know if you need help or have any questions. Best, Adrian www.tradery.com

1 0

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 18 Jan '12

18 Jan '12

On 1/11/2012 11:29 AM, Simonson, Lucanus J wrote: >The DE library description needs to be > very clear that it is for non-linear numerical optimization. I'm also > curious about how it compares industrial solvers like CPLEX. That is what I > had in mind when I said "good". It may be DE is one of the best ways to > solve a class of problems for which we don't know of a good way. There is > no point arguing about it in subjective terms, however. Instead, > quantifying how big of a problem it can handle in how many compute hours and > then providing a reference comparison to other solvers for other classes of > problem will put it into context and people will understand easily that it > is what it is and be able to tell if it is right for their problem or not. > There are people who may need it and not know it. There are people who may > need something else and not know it. The documentation should help both types of people. > Noted. In general I prefer to link to other sources that deal with the subject in much greater detail, but I can certainly add more information to help first time readers get a sense of why this library may be useful to them. > As far as design goes I would say that you want to split it into generic > genetic algorithm engine and a module for performing DE mutations. The GA > and DE-mutation modules would be configured separately and then composed to > produce the solution. That means you need to define an interface between > the GA and DE modules, but once you do that then you are able to easily swap > out GA engines or apply different mutation modules to achieve different GA > algorithms. I don't think that the mutation module needs to couple to > anything to do with the objective function at all. If someone wants to plug > in their HADOOP powered genetic algorithm instead of using the library > provided one then they would just use the DE mutations module. Alternately > they could use ASIO to build their own distributed GA module based on the > one provided by the library. There are already several policy components to allow user customization of DE, one of them being the "Mutation Policy" component. Does this address your suggestion, or are you referring to something even more general than that? Thanks, Adrian www.tradery.com

1 0

[config] How to use on Mac with C++11 dialect?
by John M. Dlugosz 17 Jan '12

17 Jan '12

I've asked this on Boost-User and had no reply. Maybe someone here would know? Using the current Boost 1.48 and the current Clang for the Apple Macintosh, when the compiler is set to accept the C++11 dialect (that is, new "auto" usage, lambda functions, rvalue references, etc.) then Boost headers choke. So currently we can use either C++11 or Boost, but not both. I'm sure it's a matter of configuration, of telling Boost headers that the compiler is indeed supporting these constructs. Can someone please point out what needs to be done? Thanks, —John

3 2

Re: [boost] compile time parser generator
by Martin Bidlingmaier 16 Jan '12

16 Jan '12

I'm not sure it's possible to get a string literal in a template< char ... > class string; 'Literals transformation is redefined into two distinct phases: raw and cooked. A raw literal is a sequence of characters of some specific type, while the cooked literal is of a separate type. The C++ literal 1234, as a raw literal, is this sequence of characters '1', '2', '3', '4'. As a cooked literal, it is the integer 1234. The C++ literal 0xA in raw form is '0', 'x', 'A', while in cooked form it is the integer 10. Literals can be extended in both raw and cooked forms, with the exception of string literals, which can only be processed in cooked form. This exception is due to the fact that strings have prefixes that affect the specific meaning and type of the characters in question.' - source: wikipedia - http://en.wikipedia.org/wiki/C%2B%2B11#User-defined_literals . Parsing string literals with constexpr is described in this article: http://akrzemi1.wordpress.com/2011/05/11/parsing-strings-at-compile-time-pa… For building the parser generator I used compile time polymorphism. Each symbol in EBNF would be represented as a class. The interface each symbol defines looks like this: struct symbol { constexpr symbol( const_string str , unsigned int begin = 0 ); //for an implementation of const_string see the article I linked constexpr bool valid(); constexpr unsigned int end(); }; For example, a symbol that parses a single character 'a' looks like this: struct sym_a { constexpr sym_a( const_string str , unsigned int begin = 0 ) : m_end ( begin >= str.size() ? 0u - 1 : //invalid index str[ begin ] == 'a' ? begin + 1 : 0u - 1 ) { } constexpr bool valid() { return m_end != 0u - 1; } constexpr unsigned int end() { return m_end; } unsigned int m_end; }; constexpr sym_a s1( "a" ); constexpr sym_a s2( "b" ); static_assert( s1.valid() , "" ); static_assert( !s2.valid() , "" ); The source for my current version of the parser generator is appended. I've also created a simple calculator that can handle + and * (and will accept any digit sequence as number, including "00000"). Notice, that currently only char strings are completely supported, defining terminals and the opt< T > operator won't work with other literals. (I know I can improve this for terminals, but I'm not sure about opt< T >.) The source compiles with gcc 4.6 and c++11 turned on without errors. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

6 19

Re: [boost] boost threads: pthread mutex priority inheritance + patches
by Jason Newton 16 Jan '12

16 Jan '12

Ack, no discussion on this since I posted it back in July. In my opensuse packages, I apply the following patch to insure priority inheritence on mutexs. I had to go inside the mutex ctor to do the work. -Jason On Wed, Jul 27, 2011 at 5:40 PM, Jason Newton <nevion(a)gmail.com> wrote: > On Wed, Jul 27, 2011 at 4:48 PM, Jason Newton <nevion(a)gmail.com> wrote: > >> For the moment, the few lines that compose the mutex class are easily >> copied so that I can do my own business inside the constructor but I expect >> others will run into this problem down the line and this solution is a bit >> unsavory. Any better advice? >> > > Actually a private copy of mutex didn't work so well overall as pthread > conditions are hard coded to > void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) > > -Jason >

2 1

"protected" APIs
by Lorenzo Caminiti 16 Jan '12

16 Jan '12

Hello all, Boost.Closure (formerly, Boost.Local) needs to use some macros, types, etc that are currently marked private in Boost.ScopeExit: BOOST_SCOPE_EXIT_AUX_TAG boost::scope_exit::aux::undeclared ... So I will move these symbols from AUX/aux to another prefix/namespace. How shall the new prefix/namespace be named? These symbols should not go into the public API of ScopeExit because they should never be used by the end user. These symbols are only meant to be used by other parts of Boost so they should use some sort of "protected" prefix/namespace. For example, I could use "detail": "aux" for ScopeExit private API and "detail" for ScopeExit API that can be used within Boost but not by general users: BOOST_SCOPE_EXIT_DETAIL_TAG boost::scope_exit::detail::undeclared However, other Boost components already use "detail" for their private API (synonymous of "aux"). So, I could use "protected" instead: BOOST_SCOPE_EXIT_PROTECTED_TAG boost::scope_exit::protected_::undeclared What's the best convention to follow here? Thanks a lot. --Lorenzo

8 8

build error in Release branch
by Barend Gehrels 15 Jan '12

15 Jan '12

Hi, I get a build error in the release branch: .../release/tools/build/v2/build/project.jam:266: unbalanced parentheses I just looked for differences in Trunk and Release and indeed that line differs. I updated the file conform trunk, locally, and I can build now. I then get the message: warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (bjam) is 2011.12.00 warning: Boost.Build core (at /home/barend/svn/boost/release/tools/build/v2) is 2011.04-svn So this might be my problem (not sure). However I'm normally using only one bjam, copying it to /usr/local/bin, but this time I cannot do that... Should I use different bjam's for Trunk/Release versions? Is this a known problem / will this be solved? Regards, Barend

2 2

[scope_exit] improvements
by Lorenzo Caminiti 15 Jan '12

15 Jan '12

Hello all, I've been working with Alex to make the following improvements to Boost.ScopeExit (as they were discussed during Boost.Local's review). The update docs: https://svn.boost.org/svn/boost/sandbox/closure/libs/scope_exit/doc/html/in… 1) It is possible to use variadic macros on compilers that support them: int r = 0, v = 0; BOOST_SCOPE_EXIT(&r, v) { r = v; } BOOST_SCOPE_EXIT_END To support compilers without variadics and for backward compatibility with previous ScopeExit versions, all macros also accepts pp-sequences: BOOST_SCOPE_EXIT( (&r) (v) ) { r = v; } BOOST_SCOPE_EXIT_END 2) It is possible to capture no variable using `void`: BOOST_SCOPE_EXIT(void) { std::cout << "cout is a global variable << std::endl; } BOOST_SCOPE_EXIT_END This same syntax works on compilers with and without variadics. 3) From within member functions, it is possible to capture the object this using `this_`: BOOST_SCOPE_EXIT(&r, v, this_) { r = this_->f(v); } BOOST_SCOPE_EXIT_END On C++11, you can also (but you don't have to) use `this`: BOOST_SCOPE_EXIT(&r, v, this) { // C++11 only. r = this->f(v); } BOOST_SCOPE_EXIT_END 4) On C++11, you can (but you don't have to) use `;` instead of BOOST_SCOPE_END. 5) On C++11, there is an additional macro that allows to capture all variables using lambda-style `&` or `=`: BOOST_SCOPE_EXIT_ALL(&, v, this) { // C++11 only. r = this->f(v); }; Or equivalently: BOOST_SCOPE_EXIT_ALL(=, &r) { // C++11 only. r = this->f(v); }; I still have to move these changes from the sandbox into trunk. Comments are welcome. Thanks, --Lorenzo

2 1

[typeof] TYPEOF(this) on MSVC 7.1 and 8.0
by Lorenzo Caminiti 14 Jan '12

14 Jan '12

Hello all, BOOST_TYPEOF(this) generates error C2355 on MSVC 7.1 and 8.0 because of a MSVC bug. The code below was suggested to workaround the problem but it only works with native typeof. Is there a way to make BOOST_TYPEOF(this) work on MSVC 7.1 and 8.0 with Boost.Typeof in emulation mode? // Adam Butcher's workaround to deduce `this` type on MSVC revision < 10. // Boost.Typeof for VC71's typeid-based workaround does not work to determine // `this` type due to error C2355 being incorrectly reported. The typical // avoidance strategy implemented below is to make an indirect compile-time // constant by assigning an enum and use that as type-index-- this only works // with the sizeof() approach and not with the typeid() approach. This does not // work in typeof emulation mode. #if BOOST_WORKAROUND(BOOST_MSVC, >= 1300) && /* MSVC 7.1 */ \ BOOST_WORKAROUND(BOOST_MSVC, <= 1400) && /* MSVC 8.0 */ \ !defined(BOOST_TYPEOF_EMULATION) /* doesn't work in typeof-emu mode */ namespace boost { namespace scope_exit { namespace aux { namespace msvc_typeof_this { template<int Id> struct msvc_typeid_wrapper { typedef typename boost::type_of::msvc_extract_type<boost::mpl::int_<Id> >::id2type id2type; typedef typename id2type::type type; }; template<> struct msvc_typeid_wrapper<4> { typedef msvc_typeid_wrapper<4> type; }; template<typename T> struct encode_type { BOOST_STATIC_CONSTANT(unsigned, value = boost::type_of::encode_counter<T>::count); typedef typename boost::type_of::msvc_register_type<T, boost::mpl::int_<value> >::id2type type; BOOST_STATIC_CONSTANT(unsigned, next = value + 1); }; template<class T> struct sizer { typedef char(*type)[encode_type<T>::value]; }; template<typename T> typename boost::disable_if< typename boost::is_function<T>::type , typename sizer<T>::type >::type encode_start(T const&); template<typename T> typename boost::enable_if< typename boost::is_function<T>::type , typename sizer<T>::type >::type encode_start(T&); template<typename Organizer, typename T> boost::type_of::msvc_register_type<T, Organizer> typeof_register_type(const T&, Organizer* = 0); } } } } #define BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) \ BOOST_PP_CAT(boost_se_thistype_index_, id) #define BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(id, new_type) \ enum { \ BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) = sizeof( \ *::boost::scope_exit::aux::msvc_typeof_this::encode_start(this)) \ }; \ typedef ::boost::scope_exit::aux::msvc_typeof_this::msvc_typeid_wrapper< \ BOOST_SCOPE_EXIT_AUX_TYPEDEF_TYPEOF_THIS_INDEX_(id) \ >::type new_type; #else // typeof(this) on other compilers are OK. #define BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(id, new_type) \ typedef BOOST_TYPEOF(this) new_type; #endif // typeof(this) For example: // within a member function BOOST_SCOPE_EXIT_DETAIL_TYPEDEF_TYPEOF_THIS(__LINE__, this_type); this_type obj = this; Thanks. --Lorenzo

1 0

[context] mini-review comments
by Jeffrey Lee Hellrung, Jr. 14 Jan '12

14 Jan '12

[Late, I know] [I'm going off http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html] [Apologies if these are just repeating previous comments!] How do you store the function and function arguments passed to the context constructor? Are they bundled into memory allocated by the stack allocator? I couldn't find it in the documentation, and whatever the answer, seems like something that should be mentioned. "The maximum number of arguments of *context-function* is defined by BOOST_CONTEXT_ARITY (default is 10) and might be changed." Hopefully you mean, more specifically, that BOOST_CONTEXT_ARITY might be *increased*. Also, consider using variadic templates if available? Great examples! Would it be possible to also show the expected output, just so the reader can verify that he or she understands what should be happening? Given that void pointers are used to communicate between contexts, I almost would've expected the context constructor to simply take a void (*)( void* ) argument and context::start to take a void* argument which would be passed to the function pointer. Can you elaborate on the rationale for the low-level interface for communicating between contexts while still providing a relatively high level interface for specifying the context function? The documentation for the stack allocator concept doesn't completely define the semantics of the size parameter of stack_allocator::allocate/deallocate. I presume it is the stack size in bytes, but that should be explicit in the documentation. And I presume allocate is only required to return a pointer to *at least* size bytes of free memory. Also, you don't mention alignment requirements; what are they? I'm somewhat surprised default_stacksize() always returns 256*1024. I think it might be safer to make this implementation-defined, but some minimum size (as with everything else in C++...). Also, strictly speaking, the documentation is incorrect. It reads "Defines a default stack size of 256 kB", but defalt_stacksize() doesn't define anything, it just returns a number. And this description is inconsistent with the remaining function descriptions. I would do: "Returns the default stack size, which is implementation-defined but at least 256 kB." In "Low level API (boost_fcontext_t)", s/stated/started/. Also, what's the magic number 262144? Oh, I see, 262144 = 256 * 1024...maybe the latter expression would be more intuitive? Again, I can guess what the output of the example would be, but would be helpful to have the expected output handy. Just a nitpick on member variable names. boost_fcontext_stack::ss_base/ss_limit: what does "ss" mean? boost_fcontext::fc_stack/fc_link: I presume the prefix "fc" is short for "fcontext", in which case, isn't it redundant? Normally I wouldn't be picky about member variable names but these are precisely the documented API. In "Rationale", you give "[o]ther low level APIs and their caveats"; I'm guessing these are, specifically, alternatives to boost_fcontext_t but are *deficient* in some respect. It might clear things up if you make that explicit, and further group "setjump()/longjmp()", "ucontext_t", and "Windows fibers" into a common heading. Overall, I think the documentation and interface are good. I didn't look at the implementation, but I did see that someone else did, so...I'm not too worried about a correct implementation. As long as there's a full suite of tests. I also didn't try to use the library, but now I'll have to find an excuse :) These are all relatively minor comments, and although I hope Oliver will address them, it won't hold up my approval of Boost.Context. - Jeff

3 7

[fusion] Getting the adapted structure's member names
by Andy Venikov 14 Jan '12

14 Jan '12

struct alien { std::string color_; std::string planet_; bool benevolent_; }; BOOST_FUSION_ADAPT_STRUCT( alien, (std::string, color_) (std::string, planet_) (bool, benevolent_) ) I know how I can get to the actual member values, i.e. I could check at<2>(anAlien) to see if I should run away or not. But what if I wanted to get to the member names? (In this example it would be "color_", "planet_" and "benevolent_") It could be very useful for example for serialization that stores not just values but also the names of the values. Printing structures to stdout for inspection would be a breeze too. Since BOOST_FUSION_ADAPT_STRUCT is a macro, surely the member names could be strigized and stored somewhere. Thanks, Andy.

2 1

__COUNTER__ vs __LINE__
by lcaminiti 13 Jan '12

13 Jan '12

Hello all, Many of Boost macro APIs PP_CAT symbols with either __LINE__ or __COUNTER__ to make them unique (MPL_STATIC_ASSERT, SCOPE_EXIT, etc). AFAIK, __LINE__ is C++03 standard while __COUNTER__ is only a MSVC extension. I think using __COUNTER__ instead of __LINE__ might allow to expand a macro multiple times on the same line... but a part from that: What's the reason for using __COUNTER__ on MSVC instead of just using __LINE__ for all compilers? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-COUNTER-vs-LINE-tp4286398p4286398.… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 6

[Boost.Move] A few notes
by Dan Ivy 13 Jan '12

13 Jan '12

Hi, I was recently trying out Boost.Move and a few issues worth sharing surfaced: 1. It would be helpful to have configuration macros to force emulation mode, even on C++11 compilers, as well as to disable move semantics altogether (that is, the conversion operators to boost::rv& should be disabled, and move/forward should return lvalue-references. BOOST_RV_REF and friends should remain intact, so that overloads remain unique.) In many cases, the higher level semantics of a program are expected to be identical under all three configurations, so having a quick way to switch between them is useful during testing/debugging. 2. Boost.Move is a little bit too opaque, as it stands. What's really missing are Boost.Move-aware type traits. Things like add_rvalue_reference are often necessary to calcuate return types of move-aware generic functions, and so on. Whether this belongs in Boost.TypeTraits or Boost.Move is a separate question. Likewise, there should be type traits to calculate the return types of boost::move and, in particular, boost::forward. On C++11, the return type of forward<T> conincides with add_rvalue_reference<T>, but not so in emulation mode, hence the necessity for this trait. 3. For some reason, the emulated boost::move is written so it doesn't accept temporaries. This doesn't play too nicely with forwarding: Unavoidably on C++03, there has to be made a choice whether forwarding functions use non-const or const-qualified references (bad wording, but you get the point), where the former accepts modifiable lvalues and rejects temporaries, and the latter does the opposite (well, sort of). Boost.Move chooses the latter. This means that while BOOST_FWD_REF parameters accept temporaries, these temporaries are bound as lvalues, which pretty much defeats the purpose of the library (note that these temporaries aren't eligible for copy-elision, since they're bound to a reference.) While there's not much you can do about it on the callee-side, callers could use boost::move on the temporaries to force them into rvalue-refs. Only that they can't. This creates a somewhat confusing situation where forwarding functions are able to take temporaries, but they won't move them, while the only things that can actually be moved are lvalues... Ultimately, this is what I suggest: First of all, have boost::move accept temporaries. Secondly, seriously consider changing the definition of BOOST_FWD_REF(T) from const T& to T&, as this would acheive two desirable, IMO, goals:: a. Forwarding functions would accept modifiable lvalues (and keep them modifiable). b. Forwarding functions would REJECT temporaries, UNLESS they're passed through boost::move, which assures that they're treated as rvalues. A few notes on the implementation: 4. There are many one-liner functions floating around that aren't declared inline. This is a big-deal for less-capable compilers, such as Sun and older versions of GCC. In fact, they simply won't inline boost::move calls without it. 5. boost::rv<T> unconditionally inherits from T, with the assumption that it would never get instanciated for non-class types, since it is only ever used as a reference. This is a false assumption in general. In the context of overload-resolution, the compiler is allowed, though not required, to instanciate the types of function parameters, even if the best overload can be determined without doing this. Consider this move-aware, but not very useful vector class: #include <boost/move/move.hpp> template <typename T> struct vector { void push_back(const T&) {} void push_back(BOOST_RV_REF(T)) {} }; int main() { vector<int> v; v.push_back(123); } The last line of main could potentially instanciate rv<int>, breaking the program. And it does. Sun falls right into this trap. It doesn't take much to make it break on GCC either, for the same reason. Fortunately, the fix is trivial: specialize boost::rv correctly for non-class types. All comments refer to the 1.48 release. I don't know what's going on on trunk. HTH

5 14

Release 1.49
by Barend Gehrels 13 Jan '12

13 Jan '12

Hi, I did not see (m)any recent mail traffic on the list w.r.t. release 1.49. According to the Calendar it was to be merged last Monday (major changes) and next Monday (all changes). Is this planning still up-to-date? Thanks, Barend

2 2

[interprocess] Crash of singleton_module in Windows
by JOAQUIN M. LOPEZ MUÑOZ 13 Jan '12

13 Jan '12

Steps to reproduce the problem: * Create singleton_dll.dll. * Create singleton_exe.exe, which uses singleton_dll.dll. * Run. On exit, an access violation happens. Seemingly, the problem happens when two different singletons are created, one in the main executable and the other in a DLL. If both singletons are created in the same module everything's OK, though. Best regards, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

4 7

[bjam] if MSVC 7.1 or 8.0 compile-fail
by lcaminiti 13 Jan '12

13 Jan '12

Hello all, If there a way to program the following within a Jamfile? import testing ; if(MSVC 7.1 or MSVC 8.0) { # How do I program this? [ compile-fail native_tu_test.cpp native_tu1.cpp native_tu2.cpp : : : <define>BOOST_TYPEOF_NATIVE ] } else { [ run native_tu_test.cpp native_tu1.cpp native_tu2.cpp : : : <define>BOOST_TYPEOF_NATIVE ] } Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-bjam-if-MSVC-7-1-or-8-0-compile-fa… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Boost.Variant] Parameterized Visitors
by Andy Jost 13 Jan '12

13 Jan '12

New poster. When I'm using Boost.Variant, I often want to pass additional parameters to a visitor. A common case is when the variant is a class member and I want to have access to other members (or even "this") in the visitor. I muddled through for a long time writing visitors with explicit constructors and data members to take whichever parameters I needed, but I finally got around to making this generic with Boost.Fusion and I love it. I'm wondering whether I should submit this for consideration as an addition to the Boost.Variant library and how. First a few questions: 1. Is there already an equivalent solution that I should be aware of? 2. Should this be considered for an addition to Boost? 3. If so, how do I begin the review process? 4. This is a small change (400 or so lines of code). Is there anyone willing to help with the logistics, testing, and/or documentation (perhaps in exchange for a credit in the docs)? Here's an example, which should be fairly self-explanatory: struct A {}; struct B {}; struct C {}; struct my_visitor1 : param_visitor<my_visitor1, bool> { result_type operator()(int, float, char, A) const {...} result_type operator()(int, float, char, B) const {...} result_type operator()(int, float, char, C) const {...} }; struct my_visitor2 : fused_param_visitor<my_visitor2, bool> { template<typename Sequence> result_type operator()(Sequence const &, A) const {...} ... }; int main() { boost::variant<A,B,C> abc; boost::apply_visitor(my_visitor1().tie(1, 3.14, 'k'), abc); boost::apply_visitor(my_visitor2().tie(1, 3.14, 'k'), abc); return 0; } In terms of technical detail, there's not much to it. The base classes provide tie() and load() methods to take arguments by reference or value, respectively. A call to one of those returns a helper object that contains a copy of the derived visitor and a fusion::vector of arguments. Visiting that causes the user-defined visitor to be called with all of the arguments. For parameter forwarding, I use an implementation of perfect forwarding based on boost/flyweight/detail/dyn_perfect_fwd.hpp (I used a default limit of 4 parameters). Thanks, Andy

2 2

tuple and virtual functions
by Mark Snelling 12 Jan '12

12 Jan '12

I'm having a problem with Boost.Tuple virtual functions. Consider the code below, I would have expected the output to be "B::foo()" but instead get "A::foo()". Am I missing something here? #include <boost/tuple/tuple.hpp> #include <iostream> class A { public: virtual void foo() { std::cout << "A::foo()" << std::endl; } }; class B :public A { public: void foo() { std::cout << "B::foo()" << std::endl; } }; boost::tuple< A > make( const A& a ) { return boost::make_tuple( a ); } int main( int argc, char* argv[] ) { B b; make( b ).get< 0 >().foo(); return 0; }

3 2

abi-compliance-checker
by Neal Becker 12 Jan '12

12 Jan '12

Sounds useful: http://forge.ispras.ru/projects/abi-compliance-checker

1 0

[context] mini-review period ended
by Giovanni Piero Deretta 12 Jan '12

12 Jan '12

Hi all, The boost.context mini-review period ended sometime betweend yesterday and today depending on your timezone. We didn't get many reviews, but we had some interesting discussions and I should be able to reach a conclusion. If anybody is still completing a review, please let me know me ASAP, otherwise I should be able to wrap everything up by this weekend and announce the results next week. Thanks for everybody that partecipated in the review and thanks to Oliver for submitting his library. -- gpd

1 0

Re: [boost] Condition Variables, POSIX signals and system time changes
by Johan Borkhuis 12 Jan '12

12 Jan '12

Vicente, > I'm reworking the timed wait interface using Boost.Chrono. In this case > you could use a steady clock to mean a MONOTONIC clock. Unfortunately my > refactoring did use pthread_condattr_setclock to force a monotonic clock > while waiting on the condition. Even if this should not be the source of > the problem as it works when you don't generate the signals, I think > that this will be better when available. I will need some time to make > this working but I hope I could release it for boost 1.50 :( Looking forward to that. For the moment we have a workaround, but I will keep an eye on changes in this area, so we can move back when this becomes available. >> The demo application shows where things go right and wrong, so hopefully >> you should be able to reproduce the issue. > > I have not understood the example completely. How do you change the time > forward or backward? Could you point me where or how do you do? by hand? Sorry, should have mentioned that. I change the time externally by hand, using the date command. When I change the time backwards (so an earlier time) the problem occurs. When I change the time forward again to a time equal to or before the time I changed the time the application continues. >> >> Again, thank you for your quick response. >> >> > Thanks for reporting this and for the application example. > Vicente Thank you for your work on this. Kind regards, Johan Borkhuis

1 0

problem in trunk with file system library
by Robert Ramey 12 Jan '12

12 Jan '12

I'm seeing this message on bunch of tests "/sierra/Sntools/extras/compilers/gcc-4.3.4/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -fPIC -Wno-long-long -ftemplate-depth-255 -DBOOST_ALL_NO_LIB=1 -DBOOST_ARCHIVE_TEST=binary_archive.hpp -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SYSTEM_DYN_LINK=1 -I".." -c -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/serialization/test/test_array_binary_archive.test/gcc-4.3.4/debug/test_array.o" "../libs/serialization/test/test_array.cpp" In file included from ../boost/filesystem.hpp:36, from ../libs/serialization/test/test_tools.hpp:5, from ../libs/serialization/test/test_array.cpp:22: ../boost/filesystem/v3/operations.hpp:139: error: extra ???;??? ../boost/system/error_code.hpp:214: warning: ???boost::system::posix_category??? defined but not used ../boost/system/error_code.hpp:215: warning: ???boost::system::errno_ecat??? defined but not used ../boost/system/error_code.hpp:216: warning: ???boost::system::native_ecat??? defined but not used This is provoked by the following code:symlink_perms = 0x4000 // on POSIX, don't resolve symlinks; implied on Windows};BOOST_BITMASK(perms); // line 139//--------------------------------------------------------------------------------------//Would it be possible to get this fixed. I don't what the exact fix is. Robert Ramey

2 1

Fwd: How to build the documentation
by Pedro Larroy 11 Jan '12

11 Jan '12

---------- Forwarded message ---------- From: Pedro Larroy <pedro.larroy.lists(a)gmail.com> Date: Sun, Dec 25, 2011 at 7:35 PM Subject: How to build the documentation To: boost-docs(a)lists.boost.org Hi I created a small patch for libs/python/doc/tutorial/doc/tutorial.qbk How can I check that it builds correctly and generates propper html? Regards. Pedro.

5 8

Re: [boost] Condition Variables, POSIX signals and system time changes
by Johan Borkhuis 11 Jan '12

11 Jan '12

Vicente, Thank you for your quick reply. I did not get the message from the mailing list, so I copied your questions into this mail. As requested I opened a ticket (ticket# 6377) and I attached the demo application to it, with a small description. > Do you mean that you are not using Boost.thread here? No, the application is running in one thread. The condition variables are used as an alternative sleep method. We discovered that other sleep-methods are even more vulnerable to time changes, and also have different responses to Posix signals. The condition variables continue to work correctly, even with Posix signals, however in combination with time changes there are some issues. In our real application we are using boost threads quite heavily though. > What do you changed exactly? Could you post a patch? I attached the demo application to the issue. It includes the regular Boost condition variable use and the changed implementation. It also includes the Posix timer code to generate the signals. I did not change the Boost code (yet), as I am not that familiar with it. > Please, could you post the test that fails and the one that succeeds, it > will help me a lot. The demo application shows where things go right and wrong, so hopefully you should be able to reproduce the issue. Again, thank you for your quick response. Regards, Johan Borkhuis

1 0

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 11 Jan '12

11 Jan '12

On 1/9/2012 12:09 PM, Simonson, Lucanus J wrote: > > > I think that numerical optimization is more general than its application to > machine learning. While you argue that you'd like to see the library go > deep in machine learning I don't see anything wrong with a general purpose > numerical optimization library. However, DE is more general than numerical > optimization, while the library seems to be an application of DE to > numerical optimization. I'm not sure that DE is even one of the best ways > to do numerical optimization (I'm pretty sure genetic algorithm is a bad > way, so I'm skeptical), and I know I'd like a more general interface to a DE > engine than one designed for numerical optimization problems. I'd like to > see the library go wide for max applicability rather than deep. Hopefully > that will keep it out of all the different cans of worms that could be > opened in each application domain. Put numerical optimization and machine > learning applications in the example code of the library and submit just the > core engine as the library itself. Narrowing the scope of a library submission > is usually the path to success. > I forwarded Ken Price (one of the DE co-authors) some of the comments I received for his view on things and here's his reply, which hopefully should clarify some of the issues that have been raised: "The skeptic is right in believing that GAs have traditionally done poorly at numerical optimization, primarily because they rely on general data manipulation operations (bit flips, exchanges, rotations, insertions, replacements...) that are not appropriate for real-parameter optimization. DE, however, was specifically designed for numerical optimization (although it has since been applied with limited success to combinatorial problems). Instead of relying on general data manipulation operations, DE's unique differential mutation operation is a real-valued vector operation that is appropriate for the numerical optimization problem domain. More than just appropriate, the differential mutation operation at the core of DE is effective because it exploits the tendency of a population to distribute itself around function contours. Randomly sampling the difference in the location of population members when they are distributed along a function's level surfaces turns out to be a very effective way to deal with some of the most challenging aspects of numerical optimization, e.g. multiple optima, parameter-dependence, slow-down at high resolution and disparate parameter sensitivities. As evidence of DE's utility as a numerical optimizer, I would offer that it has been part of Mathematica's numerical optimization toolbox for over a decade. It helped the Mathematica team win the SIAM 100-digit challenge (ten problems to ten-digit accuracy) by solving what the contest participants agreed was the contest's most difficult (numerical optimization) problem. (DE also solved one of the other problems in the contest). In the many other contests that have been held to compare numerical optimizers, DE has consistently placed at or near the top. DE is also part of the OPTIMUS package, which is highly respected and in wide use by several automobile manufactures. Alternatively, skeptics can do an Internet search and discover for themselves the enormous range of engineering problems the DE has successfully solved, nearly all of which are numerical optimization problems, often with multiple, non-linear constraints. DE has also proven effective in the domain of multi-objective numerical optimization. Finally, I would suggest that since DE is so simple and easy to implement, skeptics ought to just try it. Most people are surprised by how effective something as simple as DE can be."

2 1

[concept_check] Should OutputIterator check for output_iterator_tag?
by Ronald Garcia 11 Jan '12

11 Jan '12

Hello, In tracking down a problem with Boost.MultiArray, I'd like to write a test case that exhibits the failure. Specifically, certain iterators should be models of OutputIterator, and it's my impression that an output iterator needs to have an iterator_category that's convertible to output_iterator_tag(). However, it looks like the OutputIterator Concept checker in the concept checker library does not check that the output iterator has such an iterator_category. Is that an oversight, or is it not the case that an output iterator have a category that's convertible to output_iterator_tag? It looks like InputIterator, RandomAccessIterator concept checkers perform such a check. Thanks, Ron

3 4

Re: [boost] Proposal for a Differential Evolution C++ library
by Adrian Michel 11 Jan '12

11 Jan '12

On 1/9/2012 9:41 AM, Brian Schrom wrote: > > On 01/09/2012 09:11 AM, Paul A. Bristow wrote: >>> -----Original Message----- >>> >>> I, for one, think this looks a very useful library. >>> [...] >>> So you may need to find and drum up support from some potential (or > better still, actual) users ? >>> > I will provide a review if this library gets to review, so > far, I've not looked much at this submission. > Thanks. > I think that machine learning is an area where there is enough maturity > that implementations in Boost are desirable. > > A couple of things to consider. > > It would be desirable that the machine learning topic area be > designed a bit more comprehensively than a single library. For example, I > should be able to run a GA on the same data as the DE. I would hope > that they have the same API. This somewhat implies to me that DE/GA are > instances of training algorithms, for which, many are possible. The way I see it, the only common point between different optimization algorithms (if they are generic enough) is the objective function, which should have a very simple prototype: double f( std::vector< double > ); so in theory if different algorithms are implemented to accept the same types (in C++ sense) of objective functions, then you could run them interchangeably between GA, DE etc without any modification to the function or algorithm. > > There are many things that go into a ML solution. Data conditioning, > model training, model validation, model evaluation. Training in > batch modes, instance based, etc. Just to name a couple issues... > > Then the normal list of library desires...completely generic, optimized > for every conceivable configuration (embedded processor, server farm, > etc i.e. single process, multi-threaded, mpi, etc) > > My advice is to be prepared for the big can of worms that this topic could > potentially bring up. > I think the topic area will be a very hard sell, but would be very > useful. > There are many real-life applications that I believe would benefit immediately from a maybe less than perfect implementation, so if it were my choice, I would rather release an initial version sooner and enhance it based on experience gathered from its practical use. Adrian Michel www.tradery.com

2 2

Weak functor: Interested? (How to boost::bind to a weak_ptr)
by Vladimír Třebický 11 Jan '12

11 Jan '12

Hi! I saw people asking how to do boost::bind using a weak pointer. Generally it's not possible without first specifying what should happen if the weak_ptr cannot be converted to shared_ptr. The "weak_fn" I wrote is a small class holding a member pointer, a weak pointer and a "policy": * It is callable so you can insert it to boost::bind. * You can construct it using free function templates. * The policy says what should happen when the object is called yet the weak_ptr cannot be converted to shared_ptr. * It's implemented both using variadic templates and Boost.Preprocessor. Copy of the help comment: /** Returns a callback that can be used eg. in boost::bind. When called, it * tries to lock weak_ptr to get a shared_ptr. If successful, it calls * given member function with given arguments. If not successful, it calls given * policy functor. Built-in policies are: * * "ignore_if_invalid" - does nothing * "throw_if_invalid" - throws "bad_weak_ptr" * "return_default_if_invalid" - returns given value * * Example: * * struct Foo { * void bar(int i) { * std::cout << i << std::endl; * } * }; * * struct do_something { * void operator()() { * std::cout << "outdated reference" << std::endl; * } * }; * * int main() * { * boost::shared_ptr<Foo> sp(new Foo()); * boost::weak_ptr<Foo> wp(sp); * * boost::bind(boost::weak_fn(&Foo::bar, wp), _1)(1); * sp.reset(); * boost::bind(boost::weak_fn(&Foo::bar, wp), 1)(); * boost::bind(boost::weak_fn(&Foo::bar, wp, do_something()), 1)(); * } */ What's missing: * Cannot point to a free function. Only member functions. * ? Wdys? Vladimir.

6 16

Condition Variables, POSIX signals and system time changes
by Johan Borkhuis 11 Jan '12

11 Jan '12

I came across the following issue with condition variables. I don't know if this is an issue with my application or with Boost condition variables. First my setup. I am using Linux on an ARM system, running Boost 1.47. My application needs accurate timing, and for this I use a POSIX timer using SIGRTMIN. This part is not something that I can control, it is an external library that implements this. I use condition variables are a timing mechanism with in my software. When I use condition variables without the POSIX timer there is no problem. The timing continues correctly, even if I change the time forward or backward. When I start the POSIX timer the condition variable does not time-out when I change the time backward. It only times out when the original time (plus timeout) is reached. The code I use to create the condition variable: boost::mutex m; boost::condition_variable cond; boost::unique_lock<boost::mutex> lk(m); cond.timed_wait(lk, duration); I tested this also by extracting the code from Boost and implementing this inline. This gave the same results. When I changed the clock of the pthread condition variable to monotonic (call to pthread_condattr_setclock(&condattr, CLOCK_MONOTONIC)) the result was OK again. Is this an issue with my implementation, can I change some setting or is this a (known) issue with the Boost condition variables? If people are interested, I do have a small test application that I used to test this issue that I can post here. I don't know however what the policy is on this list wrt posting of attachments. Kind regards, Johan Borkhuis

3 2

Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance
by THOMAS JORDAN 10 Jan '12

10 Jan '12

Thomas Klimpel wrote: >THOMAS JORDAN wrote: > > Thanks, yes that would be the sensible way to proceed. > > My other question was, though - > > Does Boost::Move library rely on compiler optimisations of > > copy-elision/return value optimisation, as is the case with the Adobe > > Source Library (ASL) Move library, for example. The reason I ask is > > that I suspect the compiler I want to target is not very good at > > said optimisations. Or are there any other known factors which > > could > > mitigate > > against its effectiveness for a. n. other compiler? > Note the RVO (return value optimization) is a feature that is either working > or not, similarly to tail recursion in functional languages. This is unlike > URVO (unnamed return value optimization), which depends on the code > analysis capabilities of a optimizer. (Well, some compilers used to turn off > RVO in debug mode, but this should no longer be the case.) > Writing tests to check whether RVO is implemented is easy. I guess you > have a pretty good chance that even your compiler supports RVO (so I > guess the ASL Move library would work). But this doesn't mean that it will > be easy to get Boost.Move working with your compiler. Actually, just to clarify, I ran some tests which indicate the compiler (Sun C++ 5.10) does RVO on temporaries, but does not do NRVO and also does not seem to do copy-elision (as often as it might, at least). Now the ASL Move library does definitely depend on copy elision to provide any performance benefit, as is stated in its documentation. I tried that library and saw no gain - exactly the same call sequence took place. That seems to make sense I have pulled in the Boost::Move library - actually I only just pulled/hacked in the bare minimum, i.e., the macros and the ::boost::rv class and little else, as I am not so concerned about the C++0x/C++03/platform portability to begin with, just the performance. I got it compiling and running just before I knocked off for the day. It looks like there may be a couple fewer copies than with ASL or than without any move library, but not as much of a reduction as I wanted/expected, though I need to analyse it again more thoroughly tomorrow. It looks from the design of the boost::rv classes and associated overloads, and the conversion operators generated like the macros, that unlike ASL, Boost::Move doesn't rely on RVO/NRVO/copy elision in order to perform. Is that a reasonable assumption? Or is there anything else that people are aware of which could hinder the optimal performance of Boost::Move? Regards, T.

1 0

[range] SinglePassIterator concept check is too strict
by Nathan Ridge 10 Jan '12

10 Jan '12

Hello, It seems to me the concept checking performed by Boost.Range for the SinglePassIterator concept is too strict. In boost/range/concepts.hpp, SinglePassIteratorConcept checks for the following usage (line 157 in trunk): BOOST_DEDUCED_TYPENAME boost::detail::iterator_traits<Iterator>::reference r1(*i); This requires that the return type of operator* be convertible to the iterator's reference type. However, looking at the specification for single pass iterators [1], I don't see any requirement that the return type of operator* be convertible to the reference type - it just needs to be convertible to the value type. An example of an iterator for which the return type of operator* is not convertible to the iterator's reference type is std::istreambuf_iterator<charT>, whose reference type is charT&, but the return type of its operator* is charT. (Both of these are specified explicitly in section 24.5.3 of the C++03 standard.) As a result, code such as the following fails to compile with GCC or MSVC in C++03 mode: #include <boost/range/concepts.hpp> #include <boost/range/iterator_range.hpp> #include <iterator> #include <istream> int main() { BOOST_CONCEPT_ASSERT (( boost::SinglePassRangeConcept< boost::iterator_range< std::istreambuf_iterator<char> > > )); } (In C++11, things changed - a requirement was added that the return type of operator* be the same as the iterator's reference type, and correspondingly std::istreambuf_iterator<charT>'s reference type was changed to be charT). What can be done about this? Regards, Nate [1] http://www.boost.org/doc/libs/1_48_0/libs/iterator/doc/new-iter-concepts.ht…

3 2

[context review] Performance questions
by Antony Polukhin 10 Jan '12

10 Jan '12

I`ve read through the documentation of Boost.Context and some questions pop up: 1) What if we reimplement the ASIO example without Boost.Context (server class will look like this): class server : public boost::enable_shared_from_this< server > { private: boost::asio::ip::tcp::acceptor acceptor_; boost::array< char, 1024 > buffer_; void do_() { boost::asio::ip::tcp::socket socket( acceptor_.get_io_service() ); acceptor_.async_accept( socket, boost::bind( & server::do_1_, this->shared_from_this(), _1) ); } void do_1_(boost::system::error_code ec) { if (!ec) { socket.async_read_some( boost::asio::buffer(buffer_), boost::bind( & server::do_2_, this->shared_from_this(), _1, _2) ); } else { do_(); } } void do_2_(boost::system::error_code ec, size_t n) if (!ec) { boost::asio::async_write( socket, boost::asio::buffer( buffer, n), boost::bind( & server::do_1_, this->shared_from_this(), _1) ); } else { do_(); } } } server( boost::asio::io_service & io_service, short port) : acceptor_( io_service, boost::asio::ip::tcp::endpoint( boost::asio::ip::tcp::v4(), port) ), {} public: typedef boost::shared_ptr< server > ptr_t; static ptr_t create( boost::asio::io_service & io_service, short port) { return ptr_t( new server( io_service, port) ); } void operator()( boost::system::error_code /*ec*/, size_t /*n*/) { do_(); } }; Looks like this implementation will be faster (it has the same amount of io_service posted functions, no dynamic allocations, but has no context switches). Am I missing something? 2) Can we use contexts like condition variables? For example: struct task{ }; std::deque void thread_1() void threads

3 7

[C++ Now! 2012] Deadline extension: Call for Submissions, new deadline is January 20th, 2012
by Hartmut Kaiser 10 Jan '12

10 Jan '12

INAUGURAL C++ NOW! CONFERENCE 2012 Aspen CO, USA, May 14-18, 2012, www.cppnow.org CALL FOR SUBMISSIONS We invite you to submit session proposals to the Inaugural C++ Now! Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012). Based on the successful traditions of 5 years of BoostCon, which was the main face-to-face event for all things C++ and Boost (www.boost.org) C++Now! 2012 will present leading speakers from the whole C++ community. The conference name is changing to C++ Now! to reflect the current value of the language, the focus on its new state (from the new Standard), and the need to continually look to the future so the language remains useful to the C++ community. The focus of this conference will be the new C++11 language Standard and as usual Boost: what's new in C++, its Standard library, and in the Boost libraries, how to write and maintain them, how to evangelize or to deploy Boost within your organization. The new C++ Standard, but also the infrastructure and process of Boost, its vision and mission - no matter what you are interested in, it all comes together in the C++Now! sessions. Meet the colleagues, and feel the inspiration to support your work with C++ and Boost for the next year. The C++ Now! Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++Now! have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. IMPORTANT DATES New proposal submissions due: January 20th, 2012. UPDATED! Proposals decisions sent (tentative program): February 17th, 2012. Fully scheduled program available: February 25th, 2012. Session materials due: April 15th, 2012. BEST PRESENTATION AWARDS We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++Now! website for that year and a plaque containing all the C++Now! conference information. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * C++11 and how it changes life for users and library writers * General tutorial sessions on C++11, the C++11 Standardslibrary, and one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 and Boost. Workshops Workshops provide an active arena for advancements In Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner These were introduced at BoostCon 2008, and were a great Presentations success They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors We actively encourage tool vendors and ISP's to submit presentations proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 60 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 60 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10- 20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2012. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++Now! website and will be available to attendees. For general information on the C++Now! 2012 paper submission or the scope of technical papers solicited, please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2012(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now!. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Dave Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

2 1

[Boost.Test] g++ compilation error due to ambiguity between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if as well as the disable_if counterparts introduced after Boost 1.48.0 (up to at least svn rev. 76217)
by Torsten Maehne 10 Jan '12

10 Jan '12

Hello, I would like to draw your attention to an issue in Boost.Test that I'm experiencing with Boost trunk after the 1.48.0 release up until at least SVN rev. 76398. Just including directly or indirectly boost/typeof/ native.hpp into a unit test module (which includes boost/test/included/ unit_test.hpp) will cause compiler errors with g++: ==== begin: test_boost_test_decorator_enable_if.cpp ==== #define BOOST_TEST_MODULE test_boost_test_decorator_enable_if #include <boost/test/included/unit_test.hpp> #include <boost/typeof/native.hpp> //! \test Dummy test. BOOST_AUTO_TEST_CASE(test_dummy) { // do nothing } ==== end: test_boost_test_decorator_enable_if.cpp ==== g++ reports: In file included from test_boost_test_decorator_enable_if.cpp:62: boost/typeof/native.hpp:30: error: expected nested-name-specifier before ‘enable_if’ boost/typeof/native.hpp:30: error: expected initializer before ‘<’ token boost/typeof/native.hpp:34: error: expected nested-name-specifier before ‘disable_if’ boost/typeof/native.hpp:34: error: expected initializer before ‘<’ token The reason is an ambiguity between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if in boost/typeof/native.hpp, as well as the disable_if counterparts. The test case compiles correctly against Boost 1.48.0 using Apple g++ 4.2.1, MacPorts? g++ 4.5.3 and 4.6.2 as well as Apple clang++ 3.0 on Mac OS X Lion 10.7.2 and Xcode 4.2.1. It fails to compile against Boost trunk until at least svn rev. 76217 using any of the mentioned g++ versions. Surprisingly, clang++ 3.0 is still able to correctly compile the test case. The test case is derived from test_signed_integer_output_with_karma.cpp in Trac ticket #6126. During the discussion of ticket #6126 on the Boost- Spirit-general mailing list, Jeroen Habraken identified the header boost/ test/tree/decorator.hpp as the origin for the compilation failure of the test case against Boost trunk. He found the cause to be an ambiguity: $ g++-mp-4.6 -o test_boost_test_decorator_enable_if test_boost_test_decorator_enable_if.cpp -I.../boost-trunk In file included from test_boost_test_decorator_enable_if.cpp:58:0: boost/typeof/native.hpp:30:18: error: expected nested-name-specifier before 'enable_if' boost/typeof/native.hpp:30:27: error: expected initializer before '<' token boost/typeof/native.hpp:34:18: error: expected nested-name-specifier before 'disable_if' boost/typeof/native.hpp:34:28: error: expected initializer before '<' token These occur because the code states "typename enable_if<Cond, T>::type" and the type name doesn't make sense in combination with boost::unit_test::decorator::enable_if. When removing the typename, on gets the following ambiguity error: boost/typeof/native.hpp:30:9: error: reference to 'enable_if' is ambiguous boost/utility/enable_if.hpp:36:10: error: candidates are: template<class Cond, class T> struct boost::enable_if boost/test/tree/decorator.hpp:184:23: error: class boost::unit_test::decorator::enable_if showing the conflict between template<class Cond, class T> struct boost::enable_if and class boost::unit_test::decorator::enable_if. As enable_if is often used without being fully qualified this breaks in a major fashion. Since boost/test/tree/decorator.hpp seems to be quite new (added 2011-10-02 11:00:16 +0200) it might be best fixed there. My search on trac for boost::unit_test::decorator_enable_if turned up changeset 74663 by rogeeff, who I therefore put in CC of the ticket 6331, which describes the findings of Jeroen and me. However, there hasn't been any feedback over the past 12 days. Therefore, I'm posting it now to the Boost.Devel mailing list hoping that the issue can be resolved before Boost 1.49 is released. Regards, Torsten Maehne

1 0

Re: [boost] FW: FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 10 Jan '12

10 Jan '12

On 1/9/2012 9:11 AM, Paul A. Bristow wrote: > > I, for one, think this looks a very useful library. > > But few of the Boosters who follow these lists will be expert or even > potential users of this > 'niche' topic - which is why I think you've not had a deservedly rave > response ;-) > Thanks. I'm actually not surprised by the limited response for the exact reasons you mention, but I imagine this must have been the case with other libraries as well. > The documentation looks in a good state. The code looks clean and portable, > but finding someone to > run on a non-MSVC platforms would be useful - Boost likes to be *seen* to be > portable. > I thought that was going to be a requirement in a later stage, after the library was accepted. Nevertheless, if somebody on this list is willing to test the library on a non MS platform and using a compiler different from Visual Studio, I will appreciated your help! > The folder structure should be 'Boost standard' so that it is possible to > use bjam to build and use > Boost.Test. (Do not hesitate to ask for help - bjam is the Outer Mongolian > of computer languages > and using it is a dark art!) I'll look into it and make the necessary changes. > > You will first need to find a review manager (preferably a Boost > contributor), and it will be > necessary to have some reviewers too! (Reviewers need not necessarily be > currently active Boost > followers for a specialist library like this - expertise is the key thing). > > So you may need to find and drum up support from some potential (or better > still, actual) users ? The library was reviewed from a functional and conceptual standpoint by the creators of the DE algorithm and they seem to have validated it, maybe less so from a C++ standpoint though. I also received very useful feedback for further enhancements that I'll be adding in a future release. As far as a boost review manager and other reviewers, I can only count on list members that are willing to volunteer some of their time for this purpose (please let me know if interested). I'll also try to gather some support outside of the list. One of the nice things about DE is that it is relatively simple and generic, and it doesn't require any advanced or domain specific knowledge, so I'm sure anybody on this list could learn enough about it to be able to review the library, without spending too much time and effort. Adrian Michel www.tradery.com

2 1

Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance
by THOMAS JORDAN 10 Jan '12

10 Jan '12

>From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> >To: boost(a)lists.boost.org >Subject: Re: [boost] [Boost.Move] [Boost.Container] Compiling with > older versions of Boost and Performance >Message-ID: <4F09F0C3.4080306(a)wanadoo.fr> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed Ø Le 08/01/12 12:25, Thomas Jordan a ?crit : Ø >> Message: 3 Ø >> Date: Sat, 07 Jan 2012 15:58:20 +0100 Ø >> From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> Ø <snip> Ø >> Le 07/01/12 12:10, Thomas Jordan a ?crit : Ø >>> Hi, Ø >>> I am interested in experimenting with v1.48 Boost.Move and Ø >>> Boost.Container. However, I am otherwise constrained to using Boost Ø >>> libraries v1.33.1 with Ø >>> a Sun C++ v5.10 compiler. I couldn't seem any 'Boost library Ø >>> dependencies' listed in the Move/Container documentation, but a Ø >>> quick look through the header files suggests Ø >>> that it is mainly MPL and Type Traits. So... Ø >>> First question: would it be feasible for me to combine the headers Ø >>> for these two libraries with the v1.33.1 libraries and get it to Ø >>> work (albeit maybe with a little customisation), or would it be a Ø >>> big job/non-starter? Ø >>> Second question - I don't see any performance analysis published for Ø >>> Boost.Move. I know that move semantics is about more than improved Ø >>> performance, but am interested in that side of things, especially as Ø >>> the above compiler appears suboptimal in terms of copy elision and Ø >>> RVO. I am wondering for example whether are there any Ø >>> (compiler-specific) factors which could mitigate against the Ø >>> performance benefits of doing a move vs a copy of a vector, using Ø >>> these libraries, for example. Ø >>> Ø >> Ø >> Hi, Ø >> Ø >> unfortunately Boost.Move and Boost.Container are not working up to now Ø >> on Sun c++ even on trunk (1.49). See Ø >> http://www.boost.org/development/tests/trunk/developer/container.html. Ø >> Ø >> Best, Ø >> Vicente Ø Ø >Thanks for pointing me to that. In general is there anything more Ø >detailed than pass/fail available to look at? Ø >Is the assumption that something with so many fails it not fixable one Ø >the library side, and is not worth investigating? Ø > Ø > Ø Lastly there were some issues reporting the failure on the Sandia Ø testers. Sun compiler miss a lot of useful features for many Boost Ø libraries. Ø I think the best you can do is to install the version 1.48 (or the Ø trunk), run the tests yourself, look for the first failures in Ø Boost.Move and try to understand what is going wrong. Report the Ø failures here and try to solve them with the help of Ion and the Boost Ø comunity. Ø HTH, Ø Vicente Thanks, yes that would be the sensible way to proceed. My other question was, though - Does Boost::Move library rely on compiler optimisations of copy-elision/return value optimisation, as is the case with the Adobe Source Library (ASL) Move library, for example. The reason I ask is that I suspect the compiler I want to target is not very good at said optimisations. Or are there any other known factors which could mitigate against its effectiveness for a. n. other compiler? Regards, T.

2 1

[random] uniform_real problem (what, again?)
by Neal Becker 10 Jan '12

10 Jan '12

Testing with 1.47.0, I know we added an assert min <= max But is min==max valid? I just tried testing with a uniform_real (0,0), and it seems to hang forever. I haven't tried to fully analyze the code, but I'm guessing this could be a problem: if(result < max_value) return result; So should that assert be min < max? Also, I find it unfortunate that it is not possible to use uniform_real (x,x) as a limiting case - it occurs naturally in my code when I don't actually want to generate a range of values but just a constant value.

1 0

Boost Review Wizard Report for January 2012
by Ronald Garcia 10 Jan '12

10 Jan '12

============================================== Review Wizard Status Report for January 2012 ============================================== News ==== 1. Type Traits Library Extensions Accepted 2. AutoIndex Tool Accepted 3. Heaps Library Accepted 4. Assign v2 Library Rejected 5. Type Traits Introspection Library Accepted 6. Lockfree Library Accepted 7. Algorithm Library Accepted 8. Atomic Library Accepted 9. Local Library Accepted 10. Context Mini-review Ongoing Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Conversion - reviewed August 2011; review manager: Gordon Woodhull. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak * GIL.IO - accepted January 2011; author: Christian Henning. * Atomic - accepted July 2011; author Helge Bahmann * Lockfree - accepted August 2011; author: Tim Blechmann. * Algorithm - accepted December 2011; author: Marshall Clow The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Heaps - accepted June 2011; author: Tim Blechmann. * Type Traits Introspection - accepted August 2011; author: Edward Diener. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Log - accepted provisionally March 2010; author: Andrey Semashev. * Endian - accepted provisionally November 2011; author: Beman Dawes. After repeated failed attempts to contact the author, the following library has been marked as Orphaned. * Switch library, accepted provisionally January 2008 author: Steven Watanabe. General Announcements ===================== As always, we need experienced review managers. 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, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot 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. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. 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. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Network (M) * Singularity (M) * Predef (M) ``(M)`` marks libraries that need review managers. -------------------- 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 Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&fil…>`__ | 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. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al…>`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: The variadic_macro_data library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox <https://svn.boost.org/svn/boost/sandbox/block_ptr/>`__ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Network ------- :Author: Dean Michael Berris :Review Manager: Needed :Download: http://cplusplus-soup.com/2011/04/18/cpp-netlib-0-9-0-released/ :Description: This is a library that provides application layer protocol support using modern C++ techniques. It is light-weight, fast, cross-platform and is intended to be as easy to configure as possible. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/icaretaker/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Predef ------ :Author: Rene Rivera :Review Manager: Needed :Download: http://tinyurl.com/73n6a3k :Description: The Predef library implements two simple tasks: 1. Definition of a single version number macro to provide consistent version number at the preprocessor level. 2. A collection of detected definitions for compilers, standard libraries, architectures, operating systems, and languages. Unlike the Boost Config Library it doesn't define language features and capabilities. But only defines presence of detected compilation context. Documentation and downloads are available in the sandbox.. Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

1 0

[context] 4 days left on Boost.Context mini-review
by Giovanni Piero Deretta 10 Jan '12

10 Jan '12

Hi All, This is a call for reviewers for Boost.Context. The mini review period will end the 11th of this month and we only had 1 review so far and we were expecting a few more. We had some interesting discussions on the original review period and quite a few people were involved, so anybody who has an interest in boost.context please write a review. thank you all, -- gpd

6 12

Re: [boost] FW: Proposal for a Differential Evolution C++ library
by Adrian Michel 09 Jan '12

09 Jan '12

On 12/23/2011 10:07 AM, Dave Abrahams wrote: >> On 12.12.2011 06:52, Adrian Michel wrote: >> >> The full documentation is at http://www.amichel.com/de/doc/html but >> I'd >> suggest these pages for a first read >> http://www.amichel.com/de/doc/html/dd/d53/overview.html and >> http://www.amichel.com/de/doc/html/db/d4e/tutorial.html . > > This looks like important and useful stuff to me. > I was wondering what the status of this proposal is. So far several members have expressed interest, but there have been no new posts on this in a while, and I'm not sure what to expect next as far as the boost inclusion acceptance (or rejection) process. Adrian Michel www.tradery.com

4 3

[iterator] Combining traversal_tags with iterator_tags
by Ronald Garcia 09 Jan '12

09 Jan '12

Hi, In MultiArray I would like use iterator_facade to create an iterator that can satisfy random_access_traversal, input_iterator_tag, and output_iterator_tag. I see that in the file boost/iterator/detail/facade_iterator_category.hpp, at line 138 there is a class in the boost::detail namespace declared template <class Category, class Traversal> struct iterator_category_with_traversal So it looks like passing: boost::detail::iterator_category_with_traversal<boost::detail::input_output_iterator_tag,boost::random_traversal_tag> as the CategoryOrTraversal would be what I want. However, two components above are in the detail namespace, so I am not sure if they are meant to be used by other libraries. Is this a safe operation? Thanks, Ron Side Notes: In my searches, I found a few buggy bits in the docs and code comments: - In boost/iterator/detail/facade_iterator_category.hpp, line 76, there's a comment: // If writability has been disabled per the above metafunction, the // result will not be convertible to output_iterator_tag. This comment corresponds to behavior that was removed in changeset: https://svn.boost.org/trac/boost/changeset/21683 Now the result will never be convertible to output_iterator_tag. - In the documentation for iterator_facade, there's a bit of a booboo where the function is first written: iterator-category(CategoryOrTraversal, value_type, reference) Then defined as: iterator-category(C,R,V) So I think the argument order is flipped.

4 8

Is the review schedule up to date?
by Klaim - Joël Lamotte 08 Jan '12

08 Jan '12

Hi and happy new year, I just wanted to know if the review schedule page is currently up to date ( http://www.boost.org/community/review_schedule.html) I'm asking because I'm a bit surprised that so much proposed libraries don't have a review manager, so maybe it's just that they have not been noted on this page? Thanks. Joël Lamotte

6 5

Re: [boost] [Boost.Move] [Boost.Container] Compiling with older versions of Boost and Performance
by Thomas Jordan 08 Jan '12

08 Jan '12

> Message: 3 > Date: Sat, 07 Jan 2012 15:58:20 +0100 > From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> <snip> > Le 07/01/12 12:10, Thomas Jordan a ?crit : >> Hi, >> I am interested in experimenting with v1.48 Boost.Move and >> Boost.Container. However, I am otherwise constrained to using Boost >> libraries v1.33.1 with >> a Sun C++ v5.10 compiler. I couldn't seem any 'Boost library >> dependencies' listed in the Move/Container documentation, but a quick >> look through the header files suggests >> that it is mainly MPL and Type Traits. So... >> First question: would it be feasible for me to combine the headers for >> these two libraries with the v1.33.1 libraries and get it to work (albeit >> maybe with a little customisation), or would it be a big job/non-starter? >> Second question - I don't see any performance analysis published for >> Boost.Move. I know that move semantics is about more than improved >> performance, but am interested in that side of things, especially as the >> above compiler appears suboptimal in terms of copy elision and RVO. I am >> wondering for example whether are there any (compiler-specific) factors >> which could mitigate against the performance benefits of doing a move vs >> a copy of a vector, using these libraries, for example. >> > > Hi, > > unfortunately Boost.Move and Boost.Container are not working up to now > on Sun c++ even on trunk (1.49). See > http://www.boost.org/development/tests/trunk/developer/container.html. > > Best, > Vicente Thanks for pointing me to that. In general is there anything more detailed than pass/fail available to look at? Is the assumption that something with so many fails it not fixable one the library side, and is not worth investigating? Regards, T.

2 1

[docs][crc] Did I do new documentation correctly?
by Daryle Walker 08 Jan '12

08 Jan '12

I completely redid the documentation for Boost.CRC in changeset [76335]. It uses Doxygen and Quickbook. I guessed on how to do it by copying files from Boost.Move. But I only did stuff within the BOOST_ROOT/libs/crc/* directory. I didn't make changes to other directories, especially the BOOST_ROOT/doc/* directory. Is stuff in that directory supposed to be automatically built? Other concerns: 1. The quickbook/doxygen system doesn't seem to handle "\todo" constructs correctly. 2. Is there a way to #define various common macros, like BOOST_STATIC_CONSTANT, so they get expanded correctly in Doxygen? Is there a "Doxyfile," or can the needed Doxygen parameters be tweaked in the Jamfile.v2? 3. I guessed that the next release will be "1.49.0", is that right? 4. Content-wise, did I miss anything? Daryle W.

3 4

compile time parser generator
by Martin Bidlingmaier 08 Jan '12

08 Jan '12

Hello, with c++11's constexpr it got possible to parse strings in c++ at compile time. I've written a parser generator to create an AST for a given EBNF syntax at compile time, which can be traversed at both run time and compile time (actually, parsing can take place at run time, too, but it's probably rather slow). At the moment, the only compiler I know of that implements enough of c++11 features is gcc (version >= 4.6). Is refining my implementation worth the effort, has such a library a chance to make it into boost? Is maybe somebody already working on this? Sincerely, Martin Bidlingmaier -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone

7 10

no match for ‘operator=’ error with circular_buffer iterator when addressing buffer by reference?
by Bernd Prager 08 Jan '12

08 Jan '12

I am trying do use a circular_buffer iterator and run into problems when I try to write a copy constructor for my class. g++ (GCC) 4.5.3 generates following error: Test.cpp: In copy constructor ‘Test::Test(const Test&)’: Test.cpp:23:18: error: no match for ‘operator=’ in ‘it2 = boost::circular_buffer<T, Alloc>::begin() const [with T = int, Alloc = std::allocator<int>, boost::circular_buffer<T, Alloc>::const_iterator = boost::cb_details::iterator<boost::circular_buffer<int>, boost::cb_details::const_traits<std::allocator<int> > >]()’ /usr/local/include/boost/circular_buffer/details.hpp:253:15: note: candidate is: boost::cb_details::iterator<Buff, Traits>& boost::cb_details::iterator<Buff, Traits>::operator=(const boost::cb_details::iterator<Buff, Traits>&) [with Buff = boost::circular_buffer<int>, Traits = boost::cb_details::nonconst_traits<std::allocator<int> >, boost::cb_details::iterator<Buff, Traits> = boost::cb_details::iterator<boost::circular_buffer<int>, boost::cb_details::nonconst_traits<std::allocator<int> > >] What do I miss. Can anybody help? Thank you, -- Bernd #include <boost/circular_buffer.hpp> class Test { public: Test(); Test(const Test&); private: boost::circular_buffer<int> b; }; Test::Test() { b.resize(10); } Test::Test(const Test &t) { b.resize(10); size_t s1 = b.size(); size_t s2 = t.b.size(); boost::circular_buffer<int>::iterator it1 = b.begin(); boost::circular_buffer<int>::iterator it2 = t.b.begin(); } int main() { Test *t = new Test(); return 0; }

2 2

Re: [boost] [Boost.smart_ptr] Thread Safety
by Thomas Jordan 08 Jan '12

08 Jan '12

Message: 7 Date: Sat, 07 Jan 2012 16:49:07 -0500 From: Dave Abrahams <dave(a)boostpro.com> To: boost(a)lists.boost.org Subject: Re: [boost] [Boost.smart_ptr] Thread Safety Message-ID: <m24nw7p4j0.fsf(a)pluto.luannocracy.com> Content-Type: text/plain >on Sat Jan 07 2012, "Thomas Jordan" <thomasjordan-AT-btinternet.com> wrote: >> Hi, >> Is shared_array completely thread-safe, including >> destruction/reference counting? From the code in >> /boost/detail/sp_counted_base_pt.hpp it looks like it probably is but >> according to >> >> http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSa… >I can't reach that (very ancient) page right now, but... The documentation for this is example is the same in the latest v1.48 release. >> // thread A >> p3 = p2; // reads p2, writes p3 >> >> // thread B >> // p2 goes out of scope: undefined, the destructor is considered a "write >> access" >> >> shared_ptr isn't completely thread-safe for simultaneous read and >> write/destruct access? The same would presumbly apply to shared_array? >> Maybe I've missed something, are there compile-time configuration >> options to determine level of safety? >shared_ptr<T> is almost exactly as threadsafe as T* is. In this case, >thread A has a reference to an object on B's stack. That object is >called p2. If thread A tries to use that object's value while the >object is being destroyed, yeah, that's a race condition. >The way to avoid this situation is for thread B to pass p2 to thread A >by value, thus creating p2a, which thread A can read without concern. >Now there's no race condition. Note: this change does /not/ cause the T >object held by p2 to be copied. Thanks, I think my confusion arose from my inferring that the P2 in thread A in this example was shorthand for P2a, i.e., a copy of the actual P2 in thread B. Makes sense as per your interpretation. Regards, T.

1 0

[Boost.Poly] Runtime Concepts
by Thomas Jordan 08 Jan '12

08 Jan '12

Hi, Forgive me if this post strays into territory beyond Boost, but I was looking at the Adobe library http://stlab.adobe.com/group__poly__related.html and some of the research papers by Sean Parent et al. describing it, which I guess many people on this list will be familiar with. Is there any reason why this library/something akin has not been put into Boost? Is it simply that it will always live in Adobe Source Libraries and there is no point duplicating in Boost? Second question - the research papers on this seemed to peter out around 2009, is there any further work going on, or has this approach been taken as far as deemed interesting, or even been informally deprecated in favour of something else? Regards, T.

4 3

[Boost.smart_ptr] Thread Safety
by Thomas Jordan 07 Jan '12

07 Jan '12

Sorry, please ignore my previous post - finger trouble. The question is as follows: ------ Hi, Is shared_array completely thread-safe, including destruction/reference counting? From the code in /boost/detail/sp_counted_base_pt.hpp it looks like it probably is but according to http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSa… // thread A p3 = p2; // reads p2, writes p3 // thread B // p2 goes out of scope: undefined, the destructor is considered a "write access" shared_ptr isn't completely thread-safe for simultaneous read and write/destruct access? The same would presumbly apply to shared_array? Maybe I've missed something, are there compile-time configuration options to determine level of safety? Regards, T.

2 1

[Boost.Move] [Boost.Container] Compiling with older version of Boost and performance
by Thomas Jordan 07 Jan '12

07 Jan '12

Hi, I am interested in experimenting with v1.48 Boost.Move and Boost.Container. However, I am otherwise constrained to using Boost libraries v1.33.1 with a Sun C++ v5.10 compiler. I couldn't seem any 'Boost library dependencies' listed in the Move/Container documentation, but a quick look through the header files suggests that it is mainly MPL and Type Traits. So... First question: would it be feasible for me to combine the headers for these two libraries with the v1.33.1 libraries and get it to work (albeit maybe with a little customisation), or would it be a big job/non-starter? Second question - I don't see any performance analysis published for Boost.Move. I know that move semantics is about more than improved performance, but am interested in that side of things, especially as the above compiler appears suboptimal in terms of copy elision and RVO. I am wondering for example whether are there any (compiler-specific) factors which could mitigate against the performance benefits of doing a move vs a copy of a vector, using these libraries, for example. Regards, T.

2 1

[Boost.smart_ptr] Thread Safety
by Thomas Jordan 07 Jan '12

07 Jan '12

Hi, Is shared_array completely thread-safe. including destruction/reference counting? http://www.boost.org/doc/libs/1_33_1/libs/smart_ptr/shared_ptr.htm#ThreadSa… // thread A p3 = p2; // reads p2, writes p3 // thread B // p2 goes out of scope: undefined, the destructor is considered a "write access" /bb/source/boost/boost_1_33_1/boost/detail/sp_counted_base_pt.hpp

1 0

On the lack of manpower: (Apache stdcxx)
by Jim Bell 06 Jan '12

06 Jan '12

Though this isn't news, I just came across it and it speaks to our common problem. (And it's of interest to boost users in general.) Note that ARM and Sun are even invested in stdcxx to some extent. From Apache's C++ Standard Library project <http://stdcxx.apache.org/status/2011-02.txt>: Stdcxx continues to be dormant. All but [1] committer have moved on to other projects. The only remaining committer (the VP of the project) is too busy with his day job to make even small changes, or to put out the long-awaited patch release, stdcxx 4.2.2. A number of users and organizations have been using the project and expressed interest in contributing to it. Several submitted patches, others have offered help with the project build and test infrastructure. Unfortunately, since no committer is available to review patches and guide the contributors through the ASF process to enable them to gain commit privileges there seems to be little hope of reviving stdcxx. A possible solution that would allow contributions to resume is to grant commit privileges to the handful of contributors who have already submitted some patches or expressed serious interest in contributing going forward. Another alternative is to move stdcxx to a repository outside of ASF such as SPI (http://www.spi-inc.org/) where interested developers could start committing changes on their own right away, without going through the "training" process. This seems to the preferred solution among at least some of the interested users. Are there any other options? Future plans: Unless the issue with contributions can be resolved in the next quarter I suggest to retire the project.

5 6

[Boost.Lambda] Some new features are suggested: return, iterating yield, & local var
by Huang Huan 06 Jan '12

06 Jan '12

Hi boosters, I'm intrested in Lambda, so I have worked out some new features, and suggest boost lib add them. What can I do next? NEW features: 1. return. why lambda lib do not include this? 2. generate iterator/iteration by lambda using yield return/yield break. 3. local/global var declare and using. 1. return e.g. boost::function<char(int)> f = ( if_ ( _1 >= 0 ) [ return_('a') ], return_('b') ); p.s. return should be supported. 2. iterator/iteration generation by lambda using yield return/yield break const char* p; // we shuld use the local var inside lambda instead of this var p. refer to section 3 iteration<char> it = ( for_(var(p) = _1, *var(p), var(p)++) [ if_(*var(p) != ' ') [ yield_return(*var(p)) ] if_(*var(p) == ';') [ yield_break() ] ] ) ("I love this game; no use"); p.s. The packing iteration interface is very like the yield keyword in C# IEnumeable 3.local/global var declare and using e.g. char a; var_name x, y, z; global_var<int>(y); // put this line inside lambda is ok, just before use it ( ( local_var<int>(x), // local var declare // global_var<int>(y), var(a) = 'a', var<int>(x) = _2, // using local var x ), ( local_var<char>(z), var(a), var<int>(x) = _1, // error! x is not local var here. var<int>(y), // ok for global even if another lambda var<char>(z) = 'b', ) ) p.s. Now, in my work. It's hard to simplify var<T>(x) to var(x). It's a hard template working.

5 14

Re: [boost] [log] Status (was: Is there any interest in a Group of library like to Application System!)
by Andrey Semashev 06 Jan '12

06 Jan '12

On Wednesday, January 04, 2012 09:08:16 Renato Tegon Forti wrote: > Hi Andrey, > > Thanks for your response! What is status of your lib? Do you need any help? The library is moving slowly to v2 release. Right now I'm wrapping up bounded async frontends, I intend to finish them by the weekend. Other things left to be done before the release are: - Port filters and formatters to Phoenix v3. As a part of it, improve error messages in exceptions and make filters and formatters not throw by default. - Introduce "default" sink concept to mitigate problems with trivial and advanced logging coexistence. Trivial logging will no longer initialize the library under the hood. - Implement a common attribute registration mechanism to simplify library extension. This should solve problems with settings file parser not recognizing user-defined attribute types. - Update the documentation. There are many other things to be done but they are not showstoppers for the release. Yes, help would be much appreciated, most notably in the porting to Phoenix v3 part. If anyone is willing to help, please contact me privately or through this list.

3 9

[Graph] Concept check VertexMutablePropertyGraph
by Jens Müller 05 Jan '12

05 Jan '12

Hi, http://www.boost.org/doc/libs/1_48_0/libs/graph/doc/MutablePropertyGraph.ht… (I cannot find docs for VertexMutablePropertyGraph or EdgeMutablePropertyGraph) says that the types boost::graph_traits<G>::vertex_property_type and boost::graph_traits<G>::edge_property_type must exist. However, the concept checks (in boost/graph/graph_concepts.hpp) check for vertex_property_type<G>::type and edge_property_type<G>::type, respectively. Several questions: 1. Should there be separate docs for VertexMutablePropertyGraph and EdgeMutablePropertyGraph? 2. Should there be an actual concept check implementation for MutablePropertyGraph combining the two? 3. Should the concept check look for boost::graph_traits<G>::vertex_property_type instead of ertex_property_type<G>::type? [and the same for edge] 4. For the LEDA adapter, i.e., external adaptation, do I have to specialize vertex_property_type<G> and edge_property_type<G>? Best, Jens

2 3

[graph] VertexListGraph and InputIterator, and LEDA graph
by Jens Müller 05 Jan '12

05 Jan '12

Hi all, I'm currently fixing up leda_graph.hpp so it passes the tests, or indeed, fixing the tests ... A leda::GRAPH<int,int> (=Graph) has to fulfill VertexListGraphConcept. This means that boost::graph_traits<G>::vertex_iterator has to be a MultiPassInputIterator, i.e., also a InputIterator. I cannot read from http://www.sgi.com/tech/stl/InputIterator.html that it must be possible that you can compute the difference between two iterators. But apparently the concept check (which fails) requires a difference type, which must be a signed integer. Is this a bug in the concept check? The vertex_iterator type is defined in leda_graph.hpp using iterator_facade: class vertex_iterator : public iterator_facade<vertex_iterator, leda::node, bidirectional_traversal_tag, const leda::node&, const leda::node*> { public: vertex_iterator(leda::node node = 0, const leda::GRAPH<vtype, etype>* g = 0) : base(node), g(g) {} private: const leda::node& dereference() const { return base; } bool equal(const vertex_iterator& other) const { return base == other.base; } void increment() { base = g->succ_node(base); } void decrement() { base = g->pred_node(base); } leda::node base; const leda::GRAPH<vtype, etype>* g; friend class iterator_core_access; }; Is maybe iterator_facade insufficient? For me, bidirectional_traversal_tag does not indicate that random access is possible ... -- Jens

2 4

[chrono] Possible bug in boost::chrono::process_real_cpu_clock::now() under Windows 32bits
by ivan.lelann＠free.fr 05 Jan '12

05 Jan '12

Hi, As of 1.48 Boost.Chrono contains code below for boost::chrono::process_real_cpu_clock::now() (boost\chrono\detail\inlined\win\process_cpu_clocks.hpp) clock_t c = ::clock(); /* ... */ return time_point( duration(c*(1000000000l/CLOCKS_PER_SEC)) ); duration::rep is int64/nanoseconds, clock_t is long. This is VS2008, Win XP 32bits. I think "c" should be cast to duration::rep before being multiplied. I randomly get negative time_point and this seems to be fixed by replacing "c" with "((duration::rep) (c))" in duration constructor : duration( ((duration::rep) (c)) *(1000000000l/CLOCKS_PER_SEC)) Can someone confirm my view and that the fix is correct ? Regards, Ivan

3 3

Is there any interest in a library for Application System? (Request for comments)
by Renato Tegon Forti 05 Jan '12

05 Jan '12

Some detail (Brainstorm): This library will provide a simple way to create an application that can be: . A Server Application A server application usually starts when system boot, and then remain running as background process, don't matter who is currently logged. In Windows this will a "Windows Service" and in UNIX a "UNIX Daemon", and we can create a "Neutral Application" that is not a daemon and service, but uses "service interface" that will provide methods like an "init", "interrogate", "restart" and so on. Some type of "system global mutex" will be implemented in this flavor, then if user want, he can determine that only one instance of service will run in a system in same time. A web server, data base server and so on area examples. . A Usual Application A usual application is a normal application, that don't need all of features provided by "server application" usually is started by a user and run by a determined period. A command, mail client, MPI master/Slave and so on area examples. . Base Class Both classes will be derivated of environment class that will provide common thinks and proprieties like an "app path", "app name", "app work dir" and so on. For sample: A user that want create a server, extend your class of "server class" and then override methods that want to get needed behavior. // windows service, or daemon class myapp : public boost::application::server{}; // neutral server class myapp : public boost::application::server<neutral>{}; // usual application class myapp : public boost::application::app{}; Note that: 1) Application can be configured using Boost.Program_options 2) I want use Boost.Log to provide log functionality when available. 3) I want create a "service model" then I want use Boost.Extension to provide dynamically late bind extension (Pluf-in System). What Boosters think? This is useful or is fool lib? Boosters think that "this kind of lib" is very specific, and violate: "The library must be generally useful and not restricted to a narrow problem domain." or this kind of system is relevant to boost. Please let me know the correct way to follows! Please make suggestions! What more else? Thanks

2 2

Copyright and authorship notices
by Jens Müller 05 Jan '12

05 Jan '12

Hi all, what is the policy of adding a Copyright notice and entries to the author list when patching existing files? I found http://www.boost.org/development/requirements.html#Ownership, but it is not completely helpful. -- Jens

3 5

[thread] Boost.Thread defines boost::move which conflicts with Boost.Move
by Hartmut Kaiser 05 Jan '12

05 Jan '12

VC10, SVN trunk: #include <boost/move/move.hpp> #include <boost/thread.hpp> int main() { return 0; } Results in: .../boost/thread/detail/move.hpp(28) : error C2995: 'remove_reference<T>::type &&boost::move(T &&)' : function template has already been defined .../boost/move/move.hpp(466) : see declaration of 'boost::move' IMHO, Boost.Thread needs to be changed to rely on Boost.Move for move semantics instead of defining its own implementation for boost::move(). Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

4 13

Font used in the current Boost logo
by Mateusz Łoskot 04 Jan '12

04 Jan '12

Hi, I have tried to find what font is used in the Boost logo but without any luck. There seem to be no logo in vector format included in the trunk. The SVG file from the logo variants is not helpful: http://dbp-consulting.com/boostvariantslogo.html Does anyone know where to find the font or vector version of the logo? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 1

[geometry] GGL mailing list moved
by Mateusz Loskot 04 Jan '12

04 Jan '12

Hi, To Whom It May Concern... The Boost.Geometry library mailing list has moved from ggl at lists.osgeo.org server to geometry at lists.boost.org server. All existing subscribers and archives have been moved to the new server. The new list is available at: http://lists.boost.org/mailman/listinfo.cgi/geometry as well as listed on the main page: http://lists.boost.org/ It is also mirrored at Nabble: http://boost-geometry.203548.n3.nabble.com/ (Mirror at gmane.org may be added in future.) The old list at lists.osgeo.org will be wiped out soon. If anyone experiences any problems with the new geometry at lists.boost.org, please contact me directly. I'd like to thank OSGeo Foundation for hosting the first mailing list and the Boost mailman admins for help with the new one. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [boost] [Container] deque emplace() requirements
by Ion Gaztañaga 04 Jan '12

04 Jan '12

El 04/01/2012 12:50, Szymon Gatner escribió: > 2011/12/13 Ion Gaztañaga<igaztanaga(a)gmail.com>: >> >> You are right, it's a bug. I'll try to fix it when I get some time. >> > > Got a chance to take a look at this? I think it's fixed in trunk, you'll need to update Boost.Intrusive as well. Best, Ion

1 0

Is there any interest in a Group of library like to Application System!
by Renato Tegon Forti 04 Jan '12

04 Jan '12

I am proposing before a Log library in model of Log4cxx, but my plan is provide a full application system that will have: * Log System (Log4cxx Model) * Application System (Windows Service, Unix Daemon and Usual Application) -> Process Management (I don't know?) * Plugin System (service model): dynamically late bind extension. This will provide modular functionality that can be loaded in applications. For sample a service that can be loaded in application container, or a skin loaded in Client (MP3) Application. To illustrate: A developer that need create a server application will do: 1) Extend for "boost::application::server" and in this it use boost::log. (here if app is a Win32 then it have a Windows Service, or a daemon in unix) 2) To create service (modular application) he extend of "boost::service" to create a service and plug this service in runtime on "boost::application::server". Note that: Application can be configured using Boost.Program_options for sample. We can use Boost.Log to log, or (I don't know) we can buid Log4 model on top of Boost.Log? What Boosters think? Boosters think that "this kind of lib" is very specific, and violate: "The library must be generally useful and not restricted to a narrow problem domain." or this kind of system is relevant to boost. Please let me know the correct way to follows! Anyone that want participate is welcome! Ps: Ps: We already have some discussion in "Log Lib" topic! Thanks

3 3

Log Lib?
by Renato Tegon Forti 04 Jan '12

04 Jan '12

Is there any interest in a library to "Log" in model of Log4cxx? Thanks

2 1

Log Lib!
by Renato Tegon Forti 03 Jan '12

03 Jan '12

Is there any interest in a library to "Log" in model of Log4cxx? Thanks

6 10

[context review] Quick Review
by Stewart, Robert 03 Jan '12

03 Jan '12

Here's my quick review of the proposed Boost.Context library. I'm not familiar with the kernel-level machinations involved to save and restore the execution state managed by the context class, so I cannot comment on such implementation details and whether they satisfy the acceptance criteria. Consequently, I didn't bother to look at the implementation. The examples are good, but the discussion or comments are somewhat lacking. For example, the Enumerator example is based upon an enumerator class type which is not commented and has very little introductory text. There's a link to C# documentation on the yield keyword, but no association of enumerator's yield_return() to C#'s "yield return" statement or yield_break() to "yield break". Those associations can be inferred easily enough, but are better stated explicitly. The enumerator example is further confused by indicating that a call to yield_return() in the power derivate returns a value to the while loop in main(). What's missing is that yield_return() calls context::suspend() on enumerator's context data member which returns control to enumerator<T>::get(), which is called by main()'s while loop. The entire enumerator example should be introduced by discussing the power class first, without implementation details: class power { public: power(int _base, int _exponent); bool get(int & _value); }; Then, the example can show main(), since the above interface is sufficient. That done, the example can turn the reader's attention to how to implement power by referring to the C# yield documentation example and then relating it to Boost.Context. That will lead to the enumerator class. (Making enumerator a class template complicates matters more than necessary, BTW.) Finally, you should show expected output. I'd like to see a performance comparison of using Boost.Context versus Chris Kohlhoff's coroutines. Can his coroutines be replaced with yours without loss of efficiency? Would it require a different stack allocator to match the performance of his coroutines? (Developing the example in that direction would be useful to illustrate writing a custom stack allocator.) I don't find anything related to the Movable Stack concept suggested in the acceptance criteria. The documentation of the StackAllocator is lacking, but I've suggested a rewrite below. With that rewrite, I think it satisfies the Stack concept required for acceptance. There are no performance figures for Windows. Shouldn't there be? I think I recall that the build system doesn't support the necessary information, by default, to permit building an ABI compatible version of the library. If that's not the case, then the "How to build and install" section needs more work. Either way, the Build acceptance criteria has not quite been met yet. The _suggested_ callback-based linking was not adopted in lieu of fc_link. There should be some rationale or a FAQ for that. I've called for still more work on the documentation, but as it stands, with the concept changes I've suggested, I'm satisfied that Oliver has met the documentation acceptance criteria. _____________________________________________ Documentation comments follow. _______________ Overview This section is useful and clear, except for the second sentence of the third paragraph. It doesn't connect to the library in question as it ought and is worded a little unclearly. I'd suggest the following instead: "By contrast, transferring control within a single thread, as _context_ does, requires only a few hundred CPU cycles since it involves no system calls." You might also add something like, "which makes them useful in more contexts, particularly when implementing higher level execution control systems", to that sentence. What's missing is a Motivation section or more information in the Overview to better explain why someone would want to use Boost.Context versus other options (whatever they may be). _______________ How to build and install There should be an introductory paragraph, something like the following: "Boost.Context must be built for the particular compiler(s) and CPU architecture(s) being targeted. Each combination requires specific build command arguments as documented below." The bullets at the top of the page are only needed until the library is accepted, so be sure to remove them upon acceptance. "On POSIX and Windows systems, GNU AS and MASM are respectively required for the assembler implementation of Boost.Context" is awkward. I suggest the following instead: "Boost.Context includes assembly code and, therefore, requires GNU AS for supported POSIX systems, and MASM for Windows systems." The Note is a little awkward and includes a spelling error. I suggest the following instead: "The architecture, instruction set, and address model are optional Boost.Build properties that must be given on the bjam command line, as shown in the table below." _______________ Executing a context 3rd para: s/a function or callable object/a _context-function_/ 5th para: this should be merged with para 4 and "and might be changed" should be inside the parentheses or I don't understand how it "might be changed". 6th para, 4th sent: Add the following to the end: ", after saving the new state of the original context" 6th para, last sent: Is there anything that ensures start() is called first and only once? Example: - The control transfer comments in fn() could be a little clearer: // transfer execution control back to main() ... // execution control transferred back from main() - The first "main() calls context ctx" would be better as "main() starts context ctx" - The comment, "// ctx.suspend() was called", in the while loop is only accurate until the for loop, in fn(), terminates, right? - Expected output is not shown _______________ Transfer of data Example: - Missing comments discussing the pointers on the receiving end. For example, in fn(), I'd expect the following: void * vp = ctx.suspend(&i); // vp is &x from main()'s call to ctx.resume(&x) int j = *static_cast<int *>(vp); // j == 10 because x == 10 in main() - Expected output is not shown _______________ Exceptions in context-function s/emits/emits/ Is forced_unwind a documented exception type? That is, can it be caught explicitly? If so, the reference to "forced_unwind" should be a link to its documentation and the following might be documented as legitimate: try { // code that might throw } catch (forced_unwind) { throw; } catch (...) { // possibly not rethrow pending exception } _______________ Terminating context Shouldn't this section name be something more like, "Handling execution context termination"? 2nd example: remove the "Done" line. The "never reached" comment can then be applied to "return EXIT_SUCCESS". _______________ Chaining contexts The first two sentences should be merged something like the following: "Boost.Context provides the ability to chain context instances by passing a reference to another context, other than _not-a-context,_ as the last constructor argument." You note that the application terminates or control is transferred back to the last invocation of context::resume(). Might not the transfer also be to context::start() (if suspend()/resume() are never called)? Important: I think you mean, "context::start() must not be called on a context that is a link in the chain begun by another context. That is, call context::start() only on the first context in a chain." _______________ Unwinding stack Name this section "Stack unwinding" 2nd para, 1st bullet: Should "not-a-context" be italicized? Speaking of italics, "context" is sometimes italicized and blue and other times plain. Example: Expected output is not shown Important: s/exception!/exceptions!/ _______________ context.html Variously through this page: s/an context/a context/ or s/an context/an instance/ s/unwinds the stack before destructing it/unwinds the stack first/ s/if precondition is not fulfilled/if a precondition is not satisfied/ s/nxt is linked/nxt becomes a subsequent link in a chain/ s/the execution control/execution control/ s/The execution control/Execution control/ s/Destroyes/Destroys/ Is the move assignment operator safe against self-move assignment? start(): s/with wich/with which/ s/When the function returns/Upon return/ (to avoid confusion about whether start() or fn() has returned) resume(): s/back resuming/back, resuming/ s/ (means suspend()/, which means that suspend() returns/ (note the formatting of "returns" should be normal, not code) "[[Returns:]" is malformed Effects could be rewritten, something like the following, to be clearer: "None, if *this was not suspended by a previous call to suspend(). Otherwise, execution control is transferred back to the caller of suspend(), thereby resuming *this. The argument, vp, will be returned by the previous call to suspend()." suspend(): I think Effects is incomplete. There are spelling errors. How about the following? "Transfers execution control to the caller of the most recent call to start() or resume(). The argument, vp, will be returned by start() or resume()." unwind_stack(): Effects: suggestion: "Destroys all objects allocated on the stack, owned by *this, in the reverse order of their allocation." Non-member function swap(): Effects: suggestion: "As if l.swap(r)." _______________ Stack allocation 1st para: - "stack allocator" should probably be italicized rather than rendered as code. - Concept names are usually rendered with camelcase. Thus, s/stack-allocator/StackAllocator/. 2nd para: This should be the start of a "StackAllocator Concept" section: "StackAllocator Concept "A stack allocator must satisfy the StackAllocator concept requirements shown in the following table, in which a is an object of a StackAllocator type, p is a void *, and s is a std::size_t: " " Expression | Return type | Notes " ----------------------------------------------- " a.allocate(s) | void * | Returns a pointer to s bytes allocated from the stack " ----------------------------------------------- " a.deallocate(p, s) | void | Deallocates s bytes of memory beginning at p, a pointer previously returned by alloc.allocate()" The current documentation of allocate() and deallocate() are no longer needed. Important: This should be rephrased in terms of the concept to something like the following: "The implementation of allocate() might include logic to protect against exceeding the context's available stack size rather than leaving it as undefined behavior." You might add a note that the result of calling deallocate() with a pointer not returned by allocate() results in undefined behavior. _______________ Helper functions 1st para: s/an easy/easy/ _______________ Low level API (boost_fcontext_t) You refer to "ucontext_t" with no link or description. The example code is out of place without first seeing the documentation of boost_fcontext_t and related functions. Following the -> navigation order, the example comes first. Commenting the example and providing an introduction explaining what it illustrates would work. There is no expected output shown for the example. Presumably, the low level API is the part to port to new platforms, yet you don't state that. _______________ Struct boost_fcontext_t and related functions There is no documentation for boost_fcontext_t, particularly as it appears to be just an alias for boost_fcontext. I thought for a moment that you intend to permit different platforms to redefine the typedef to refer to different structures, as needed, but you've documented boost_fcontext_stack's ss_base and ss_limit fields, which suggests that you intend those to be part of the low level, yet documented, API. The result is that I can't figure out the purpose of the typedef. The "fc_" prefix makes sense, since it is used in boost_fcontext. By contrast, the "ss_" prefix does not make sense. I could see "fcs_", for example. ss_limit: Is the stack defined by [ss_base, ss_limit) or [ss_base, ss_limit]? "Pointer to the bottom of the stack" is ambiguous. fc_stack: The description is a little off. How about, "Tracks the memory for the context's stack"? fc_link: The description could be improved: "The address of the next context link in a chain, if any." boost_fcontext_start(): Effects are a little confusing. My suggestion: "Stores the current context data (stack pointer, instruction pointer, and CPU registers) to *ofc and restores the context data from *nfc, which implies jumping to *nfc's execution context. This function must be called when first entering *nfc's execution context." boost_fcontext_start(): Need a "Returns:" "The result of calling boost_fcontext_jump()." boost_fcontext_jump(): This likewise needs some work: Effects: "Stores the current context data (stack pointer, instruction pointer, and CPU registers) to *ofc and restores the context data from *nfc, which implies jumping to *nfc's execution context. The pointer argument, vp, is passed to the current context to be returned by the most recent call to boost_fcontext_start() or boost_fcontext_jump() in the same thread." Returns: "The third pointer argument passed to the most recent call to boost_fcontext_jump(), if any." boost_fcontext_make(): Precondition: s/finished /finishes, / and s/inside/in/ boost_fcontext_make(): Effects: s/if the context is activated next time/when the context is activated next/ _______________ Continuation 1st para: s/from Java/from the Java/ 2nd para: s/for functors objects/for a functor/ 3rd para: You say the co-routines run "in parallel", but there is no parallelism, so you should be clear about what does occur. _______________ ASIO 2nd para: s/a echo/an echo/ 3rd para: I quickly got lost in this description because it assumes familiarity with code presented later. It also assumes familiarity with control flow in Asio which can be described rather than assumed. 3rd para: s/reentered a/reentered, a/ s/a asynch./an async/ 4th para: s/adavantage/advantage/ s/bind()-version/bind() version/ s/easier implemented/more easily implemented/ s/For instance if/For instance, if/ s/a message is partialy received/only part of a message is received/ s/parser or serviced)/parsed or serviced),/ _______________ Performance The bullets are too terse. Perhaps the following captures your intent: "Performance of Boost.Context was measured on the platforms shown in the following table. Performance measurements were taken using rdtsc, with overhead corrections, on x86 platforms. In each case, stack protection was active, cache warm-up was accounted for, and the one running thread was pinned to a single CPU. The code was compiled using the build options, 'variant=release cxxflags=-DBOOST_DISABLE_ASSERTS'. "The numbers in the table are the number of cycles per iteration, based upon an average computed over 1000 iterations." _______________ Rationale NoThrow guarantee: I think you meant the following: "Member functions of context do not throw exceptions but do require that certain preconditions are satisfied: context jumps can only be made by instances which are not a _not-a-context_ and which are not complete." Pimpl idiom, 1st para: s/ it was required to separate both features in separate classes via pimpl idiom/, the use of the Pimpl Idiom was necessary/ Pimpl idiom, 3rd para: I suggest the following: "The Pimpl Idiom allows type-erasing the _stack-allocator_ type." Unwinding: s/resource/resources/ and s/a exception/an exception/ Protecting the stack: There are many changes to make here, so I'll suggest this rewrite: "Because the stack's size is fixed -- there is no support for split stacks -- it is important to protect against exceeding the stack's bounds. Otherwise, in the best case, overrunning the stack's memory will result in a segmentation fault or access violation and, in the worst case, the application's memory will be overwritten. stack_allocator appends a guard page to the stack to help detect overruns. The guard page consumes no physical memory, but generates a segmentation fault or access violation on access to the virtual memory addresses within it." setjmp()/longjmp(): s/The C99/C99/ s/frame, e.g. jumping/frame. Therefore, jumping/ ucontext_t: I don't know why anything in this section is included after the first sentence. ucontext_t, para 1: s/makecontext():/makecontext() is:/ ucontext_t, para 2: s/alter/later/ I would omit the "The signature of func is" part. That's clear from the makecontext() function pointer argument. Windows fibers: s/befor/before/ _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

[thread] feature request priority
by Vicente J. Botet Escriba 03 Jan '12

03 Jan '12

Hi, here they are a list of 26 feature requests for Boost.Thread. The features are classified as high, middle and low cost (form my point of view of course) I would like to know which features would you like to find on the next release. Please could you choose 3 features and if possible one for each category, the idea been to provide 1 high, 1 middle and 2 low features for the next release. High #2100 <https://svn.boost.org/trac/boost/ticket/2100> thread fails to compile with -fno-exceptions <https://svn.boost.org/trac/boost/ticket/2100> #6195 <https://svn.boost.org/trac/boost/ticket/6195> Provide the standard time related interface using Boost.Chrono <https://svn.boost.org/trac/boost/ticket/6195> #6217 <https://svn.boost.org/trac/boost/ticket/6217> Make uniform Boost.Thread and Boost.Interprocess synchronization interface <https://svn.boost.org/trac/boost/ticket/6217> #6230 <https://svn.boost.org/trac/boost/ticket/6230> Follows the exception reporting mechanism as defined in the c++11 <https://svn.boost.org/trac/boost/ticket/6230> #5150 <https://svn.boost.org/trac/boost/ticket/5150> boost::thread does not print or return the error value when creating a thread fails. <https://svn.boost.org/trac/boost/ticket/5150> #6194 <https://svn.boost.org/trac/boost/ticket/6194> Adapt to Boost.Move <https://svn.boost.org/trac/boost/ticket/6194> Middle #2741 <https://svn.boost.org/trac/boost/ticket/2741> proposal to manage portable and non portable thread attributes <https://svn.boost.org/trac/boost/ticket/2741> #2880 <https://svn.boost.org/trac/boost/ticket/2880> Request for Thread scheduler support for boost .. <https://svn.boost.org/trac/boost/ticket/2880> #3696 <https://svn.boost.org/trac/boost/ticket/3696> Boost Thread library lacks any way to set priority of threads <https://svn.boost.org/trac/boost/ticket/3696> #4710 <https://svn.boost.org/trac/boost/ticket/4710> Missing async() <https://svn.boost.org/trac/boost/ticket/4710> #4725 <https://svn.boost.org/trac/boost/ticket/4725> Synchronization and shared mutex's Get total_count <https://svn.boost.org/trac/boost/ticket/4725> #5173 <https://svn.boost.org/trac/boost/ticket/5173> boost::this_thread::get_id is very slow <https://svn.boost.org/trac/boost/ticket/5173> #5425 <https://svn.boost.org/trac/boost/ticket/5425> This patch will allow the user to obtain the users thread pointer from a thread group. <https://svn.boost.org/trac/boost/ticket/5425> #5956 <https://svn.boost.org/trac/boost/ticket/5956> Add optional stack_size argument to thread::start_thread() <https://svn.boost.org/trac/boost/ticket/5956> #6227 <https://svn.boost.org/trac/boost/ticket/6227> Use of variadic templates on Generic Locking Algorithms on compilers providing them <https://svn.boost.org/trac/boost/ticket/6227> #6228 <https://svn.boost.org/trac/boost/ticket/6228> Add promise and futures constructor with allocator following the standard c++11 <https://svn.boost.org/trac/boost/ticket/6228> #6229 <https://svn.boost.org/trac/boost/ticket/6229> Rename the unique_future to future following the c++11 <https://svn.boost.org/trac/boost/ticket/6229> Low #1789 <https://svn.boost.org/trac/boost/ticket/1789> thread_group not passing variables <https://svn.boost.org/trac/boost/ticket/1789> #1850 <https://svn.boost.org/trac/boost/ticket/1850> request for unlock_guard (and/or unique_unlock) to compliment lock_guard/unique_lock <https://svn.boost.org/trac/boost/ticket/1850> #2361 <https://svn.boost.org/trac/boost/ticket/2361> thread_specific_ptr: nature of the key, complexity and rationale <https://svn.boost.org/trac/boost/ticket/2361> #2637 <https://svn.boost.org/trac/boost/ticket/2637> shared mutex lock <https://svn.boost.org/trac/boost/ticket/2637> #3567 <https://svn.boost.org/trac/boost/ticket/3567> Request for shared_lock_guard <https://svn.boost.org/trac/boost/ticket/3567> #6224 <https://svn.boost.org/trac/boost/ticket/6224> Add the use of standard noexcept on compilers supporting them <https://svn.boost.org/trac/boost/ticket/6224> #6225 <https://svn.boost.org/trac/boost/ticket/6225> Add the use of standard =delete defaulted operations on compilers supporting them <https://svn.boost.org/trac/boost/ticket/6225> #6226 <https://svn.boost.org/trac/boost/ticket/6226> add explicit bool conversion from locks <https://svn.boost.org/trac/boost/ticket/6226> #6231 <https://svn.boost.org/trac/boost/ticket/6231> Add BasicLockable requirements in the documentation to follow c++11 <https://svn.boost.org/trac/boost/ticket/6231> Patches are welcome for any feature. Note that a feature that have all the needed patches, code, doc and tests could be included soon. Thanks in advance, Vicente

3 7

[thread] Reducing the number of open tickets.
by Vicente J. Botet Escriba 03 Jan '12

03 Jan '12

Hi, I have committed the following tickets in trunk. Fixed Bugs: * [@http://svn.boost.org/trac/boost/ticket/2639 #2639] documentation should be extended(defer_lock, try_to_lock, ...). * [@http://svn.boost.org/trac/boost/ticket/3762 #3762] Thread can't be compiled with winscw (Codewarrior by Nokia). * [@http://svn.boost.org/trac/boost/ticket/3885 #3885] document about mix usage of boost.thread and native thread api. * [@http://svn.boost.org/trac/boost/ticket/3975 #3975] Incorrect precondition for promise::set_wait_callback(). * [@http://svn.boost.org/trac/boost/ticket/4480 #4480] OpenVMS patches for compiler issues workarounds. * [@http://svn.boost.org/trac/boost/ticket/4819 #4819] boost.thread's documentation misprints. * [@http://svn.boost.org/trac/boost/ticket/5423 #5423] thread issues with C++0x. * [@http://svn.boost.org/trac/boost/ticket/5739 #5739] set-but-not-used warnings with gcc-4.6 * [@http://svn.boost.org/trac/boost/ticket/6168 #6168] recursive_mutex is using wrong config symbol (possible typo). * [@http://svn.boost.org/trac/boost/ticket/6200 #6200] patch to have condition_variable and mutex error better handle EINTR. These are tickets with a simple solution or that had associated a complete patch or a clear solution. Anthony I would prefer that you do the merge so that you can check what goes on the release version. I have not closed the tickets. These tickets have just release 1.49 as Milestone. Please, close them when you merge to release. There were 113 tickets two days ago. There are now 114 tickets associated to Boost.Thread. I have closed some duplicates, but some news tickets have been created since. I would like to reduce by 10% the number of tickets every month. I encourage the Boost users that have created tickets for Boost to provide a clear an complete patch when possible so that we can reduce together the number of tickets associated to this Boost library and make it more portable/usable. Don't forget to provide tests that make evident the bug, or to add doc when you are proposing a anew feature. There are a lot of tickets associated to move semantics emulation. I have created a ticket to adapt Boost.Thread to Boost.Move hoping most of these bugs will be solved. As posted in another thread there is already a patch using Boost.Move that could be a good starting point. Of course the help offered by Ion will be too much appreciated. I have created another to adapt the interface to Boost.Chrono, but I will prefer to take care of this once the one for Boost.Move adaptation is committed, as the chance of collisions is big. On the mean time I will continue with some tickets specific to Windows platform. Best, Vicente

4 12

[C++ Now! 2012] Reminder: Call for Submissions, deadline is January 10th, 2012
by Hartmut Kaiser 03 Jan '12

03 Jan '12

INAUGURAL C++ NOW! CONFERENCE 2012 Aspen CO, USA, May 14-18, 2012, www.cppnow.org CALL FOR SUBMISSIONS We invite you to submit session proposals to the Inaugural C++ Now! Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012). Based on the successful traditions of 5 years of BoostCon, which was the main face-to-face event for all things C++ and Boost (www.boost.org) C++Now! 2012 will present leading speakers from the whole C++ community. The conference name is changing to C++ Now! to reflect the current value of the language, the focus on its new state (from the new Standard), and the need to continually look to the future so the language remains useful to the C++ community. The focus of this conference will be the new C++11 language Standard and as usual Boost: what's new in C++, its Standard library, and in the Boost libraries, how to write and maintain them, how to evangelize or to deploy Boost within your organization. The new C++ Standard, but also the infrastructure and process of Boost, its vision and mission - no matter what you are interested in, it all comes together in the C++Now! sessions. Meet the colleagues, and feel the inspiration to support your work with C++ and Boost for the next year. The C++ Now! Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++Now! have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. IMPORTANT DATES New proposal submissions due: January 10th, 2012. Proposals decisions sent (tentative program): February 17th, 2012. Fully scheduled program available: February 25th, 2012. Session materials due: April 15th, 2012. BEST PRESENTATION AWARDS We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++Now! website for that year and a plaque containing all the C++Now! conference information. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * C++11 and how it changes life for users and library writers * General tutorial sessions on C++11, the C++11 Standardslibrary, and one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 and Boost. Workshops Workshops provide an active arena for advancements In Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner These were introduced at BoostCon 2008, and were a great Presentations success They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors We actively encourage tool vendors and ISP's to submit presentations proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 60 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 60 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10- 20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2012. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++Now! website and will be available to attendees. For general information on the C++Now! 2012 paper submission or the scope of technical papers solicited, please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2012(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now!. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Dave Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

How to get involved ?
by Vijeenrosh PW Vijeen 03 Jan '12

03 Jan '12

Good Morning , My name is Vijeenrosh P.W . Iam an Computer Science and Engineering student . I have knowledge in c,c++,python and linux , and an mind to extend my areas of knowledge. Recently while passing through the list of GSOC accepted organizations I met with boost libraries . it fits me since I have C++ && programming knowledge and is ready to work . I would like to know how to begin to contribute to the project . Where to begin . or is there any warm up excersices to get passed ? -- Vijeenrosh P.W CSE S3 blog : www.BlackJackVijeen.blogspot.com

4 3

RFC: Multiprecision arithmetic library
by John Maddock 03 Jan '12

03 Jan '12

Folks, I'd like to get some feedback on a multiprecision arithmetic library I've been preparing for possible Boost inclusion. The code is in the sandbox under the "big_number" directory. Docs can be viewed online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… The main features are: * A generic front-end that's capable of wrapping almost any type that's a "number". The front end is expression template enabled and handles all the expression optimization and code reduction. For example it's possible to evaluate a polynomial using Horner's rule without a single temporary variable being created. * A series of backends that need only provide a reduced interface and set of operations, implement the actual arithmetic, currently supported backends are: Integer Types ~~~~~~~~~ 1/ GMP (MPZ). 2/ libtommath. Rational Types ~~~~~~~~~~ 1/ GMP (MPQ). [ But note that the integer types can also be used as template aruments to Boost.Rational ] Floating Point Types ~~~~~~~~~~~~~~ 1/ GMP (MPF) 2/ MPFR 3/ cpp_float - an all C++ Boost-licensed backend based on Christopher Kormanyos' e_float code. [ Note these three types are fully compatible with Boost.Math Trunk - so you get full standard library plus special function support ] There's still a bunch to do, but I'd like to see what folks think, and where the main priorities should be before submission. Thanks in advance, John.

12 19

[test] showtopper for release 1.49 - std::forward not found when compiling with clang 3.0 c++0x mode.
by Vicente J. Botet Escriba 03 Jan '12

03 Jan '12

Hi, I have created a show stopper ticket https://svn.boost.org/trac/boost/ticket/6345 as after updating the trunk, I'm unable to test any library using Boost.Test. Recent modification on Boost.Test make it unusable with clang 3.0 c++0x due to std::forward missing or not found. clang-darwin.compile.c++ ../../../bin.v2/libs/thread/test/test_thread.test/clang-darwin-3.0x/debug/threading-multi/test_thread.o In file included from test_thread.cpp:16: In file included from ../../../boost/test/unit_test.hpp:19: In file included from ../../../boost/test/test_tools.hpp:328: In file included from ../../../boost/test/tools/impl.hpp:25: ../../../boost/test/tools/assertion.hpp:278:21: error: no member named 'forward' in namespace 'std' : m_value( std::forward<T>(val) ) ~~~~~^ ../../../boost/test/tools/assertion.hpp:278:29: error: 'T' does not refer to a value : m_value( std::forward<T>(val) ) ^ The revision is https://svn.boost.org/trac/boost/changeset/75370 #ifndef BOOST_NO_RVALUE_REFERENCES explicit value_expr( T&& val ) : m_value( std::forward<T>(val) ) #else explicit value_expr( T const& val ) : m_value( val ) #endif #ifndef BOOST_NO_RVALUE_REFERENCES operator->*( T&& v ) const { return value_expr<T>( std::forward<T>( v ) ); } #else operator->*( T const& v ) const { return value_expr<T>( v ); } #endif This has as consequence that the authors developing mainly with this compiler and using Boost.Test to be unable to deliver new modifications. I have added #include <utility> without success. I guess that the standard library doesn't provides this function even if the compiler provides rvalue references. The code should test for a macro that states if std::forward is available. Please could someone help on this issue? Best, Vicente

5 6

[Boost.Math] Re: [Monotone-debian] Bug#653764: FTBFS with Boost 1.48: lgamma_small.hpp:483:38: error: expected primary-expression before 'do'
by Steve M. Robbins 02 Jan '12

02 Jan '12

Hello, Boost Developers: I recently did rebuilds of all Debian packages that use Boost with Boost 1.48 and this is one of the casualties of the upgrade (from 1.46.1). On Sat, Dec 31, 2011 at 12:02:37PM +0100, Zack Weinberg wrote: > On Fri, Dec 30, 2011 at 9:53 PM, Steve M. Robbins <smr(a)debian.org> wrote: > > This package failed to build using the newest Boost version 1.48: > ... > > /usr/include/boost/math/special_functions/detail/lgamma_small.hpp: In function 'T boost::math::detail::lgamma_small_imp(T, T, T, const mpl_::int_<0>&, const Policy&, const L&)': > ... > > /usr/include/boost/math/special_functions/detail/lgamma_small.hpp:483:38: error: expected primary-expression before 'do' > > I'm not in a position to verify this for myself for another week, but > I have a horrible feeling I know what's wrong: Monotone defines > several one-character macros for its own use, and L() is one of them. > It looks like Boost is using L() for its own purposes and expecting it > not to be a macro. Zack, you are absolutely right. The lgamma_small header has a templated class method using "L" as one of the templates: template <class T, class Policy, class L> T lgamma_small_imp(T z, T zm1, T zm2, const mpl::int_<0>&, const Policy& pol, const L&) The compile error at line 483 is at a call to L(): result = log(gamma_imp(z, pol, L())); > I'd argue that Boost headers should take care to defend themselves > from the possibility of such macros, but fixing that in Boost might be > an enormous amount of work, and in any case, 1.48 is already out > there. Boost.Math developers: What is the right thing to do here? More descriptive class template parameters? Attached is a trivial file to reproduce the bug. Thanks, -Steve

6 6

boost modularisation status?
by Robert Ramey 02 Jan '12

02 Jan '12

https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus hasn't been modified in 3 years. Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this. What is the current status of this? Robert Ramey

9 22

[review] Boost.Context mini-review starts today, January 2nd
by Giovanni Piero Deretta 02 Jan '12

02 Jan '12

Hi all, we will start a new year of Boost reviews with a one week mini-review of the Boost.Context library of Oliver Kowalke. The review period starts today January 2nd and ends January 11. Please use [context review] as prefix of your post. Reviewers are strongly encouraged to send their reviews to the boost development mailing list as this is the I follow more assiduously. Please note that Boost.Context was already reviewed and conditionally accepted last May, so we are not voting for acceptance. Instead, this mini-review is to discuss whether the library meets the conditions on acceptance that were listed by Vicente Botet, the review manager at that time. You'll find the whole list at the end of this email. Since the end of the original review, Oliver has spent a large amount of time on a partial rewrite of the library and both me and Oliver decided to schedule this review only after we determined that all issues had been addressed or at least considered. In your review please state whether the acceptance conditions have been addressed satisfactorily. ---------------------------------------------------------------------------------- About the library: Boost.Context is a foundational library that provides a sort of cooperative multitasking on a single thread. By providing an abstraction of the current execution state in the current thread, including the stack (with local variables) and stack pointer, all registers and CPU flags, and the instruction pointer, a context instance represents a specific point in the application's execution path. This is useful for building higher-level abstractions, like coroutines and fibers. ---------------------------------------------------------------------------------- Useful Links: documentation: http://ok73.ok.funpic.de/boost/libs/context/doc/html/ library: git://github.com/olk/boost.context.git ---------------------------------------------------------------------------------- >From the original review result email: Point to be addressed before the mini review: Design 1. Separation of the context class in two interface: - A C-like interface that defines a POD struct that is memcpy-able and that can be implemented either using platform libraries, as ucontext, fibers or directly using assembler when a robust implementation is available. The context swap implementation don't need to save the signals as ucontext does. The following is just for illustrations purposes. struct boost_context; typedef void boost_context_fn_t(intptr_t); extern "C" void boost_context_make(boost_context* ctx, boost_context_fn_t * f, intptr_t p, ...); extern "C" void boost_context_swap(boost_context* from, boost_context const* to); extern "C" intptr_t boost_context_destroy( boost_context* fc); boost_context_make is a merge of get_context with make_context + some fields assignations. "A user will have lower expectations from such a low level API and at the same time will give more freedom for other people to implement on top of it higher abstractions as Boost.Corutines, Boost.Fibers ..." - A non-copiable but movable safe context class on top of the low level C-like interface, that will provide modern and efficient C++ interface, that is usable by a user in a safe way. The safe context class would just be one of the client of the C-like interface, other library authors could either use the underlying C-like API directly or the class context depending on wether they need the speed or safety. * The context class will not be templated any more, and the use of type erasure will ensure that. * The constructor will accept any C++ callable, function pointers, functors, ... * At this high level interface, the function provided by the user could throw exceptions, and the library must wrap the user function and needs to store the exception raised and provide an interface to retrieve them. 2. The stack implementation must ensure that the stack is unwound before it is destroyed. A stack should only be safely deallocated if either has been completely unwound or if it doesn't own any resources. A basic stack without protection seems mandatory. For debug purposes it has been required to provide some stack usage functions that allow to know the max size used for example. Implementation 3. The assembler implementation on Windows must be disallowed if the ABI bug reported by Holger is confirmed. As far as Windows provides a fiber implementation that is as efficient as the assembler one, the assembler implementation is not mandatory and the user of the provided Windows fiber is a preferable choice. 4. Most of the 'throw' statements in the context class should actually be asserts. 5. The provided stack should be used to store any context parameters as far as no major impediment is found during the implementation. This will avoid further allocations on the safe context class. Documentation 6. The documentation is very minimalist and should be expanded with a discussion on context switching and use cases. Take care of all the grammar/spelling improvements suggested by the reviewers (It will be great if Jeffrey could review the documentation before the mini-review). Some user land examples should be provided (why not the yield example). 7. The concept of (Movable) Stack must be clearly defined, as it is done in the standard, using expression requirements with semantic constraints. 8. The assembler implementation should be carefully documented, so others could maintain the code and add other implementations if needed. 9. Some performance measure should be added. Providing the number of cycles on each implemented platform would be nice. Build system 10. The default build on a platform must work (It must be ABI compatible with the underlying platform) and take care of the specific features. Of course, the build needs to support cross compiling, so the user should be able to override the default values. Others points that are not required but that can make the library more usable or efficient: 1. The assembler implementations could be simplified if the context itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the context struct and back. 2. Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contexts), while the having the callback return the 'next continuation' has more applications (note that fc_link can be implemented easily in term of the continuation returning variant, but the reverse is harder). This will be very useful, for example, to implement some kind of 'exit_to' functionality (unwind the stack and restore another context), a key piece for safe context destruction. 3. Give to boost_context_swap the ability to exchange a parameter with the other context: boost_context_parm_t boost_context_swap( boost_context * ofc, boost_context const* nfc, boost_context_parm_t parm) where boost_context_parm_t is either union boost_context_parm_t { void * ptr; int int_; }; or simply intptr_t; boost_context_swap saves the current context in ocf and restores the context ncf as usual; additionally, if ofc was 'captured' on a call to boost_context_swap, this call will return the value of parm on the original context. This extra parameter is equivalent to the second parameter of longjmp. If ofc was created with boost_context_swap, 'parm' will be an extra parameter to the function. Note that this can be potentially implemented with little or no overhead. 4. Add a variant of boost_context_swap that allows executing a function on the destination context (in this case 'parm' would be passed parameter to this function. This is mostly useful for injecting an exception on the destination context. This can be potentially implemented on top of the existing functionality, but would slow down every context switch; a possible efficient implementation would manipulate the destination stack to add a call to the function on top of it, so that the cost is paid only when required. 5. Add a current context function (thread local).

1 0

[Graph] LEDA adapter - concept check VertexListGraph fails
by Jens Müller 01 Jan '12

01 Jan '12

Hi everyone, when running the tests for Graph, the first concept check in leda_graph_cc.cpp fails: gcc.compile.c++ ../../../bin.v2/libs/graph/test/leda_graph_cc.test/gcc-4.6.1/debug/leda_graph_cc.o In file included from leda_graph_cc.cpp:9:0: ../../../boost/graph/graph_concepts.hpp: In destructor 'boost::concepts::VertexListGraph<G>::~VertexListGraph() [with G = leda::GRAPH<int, int>]': ../../../boost/graph/graph_concepts.hpp:168:1: instantiated from 'static void boost::concepts::requirement<boost::concepts::failed************ Model::************>::failed() [with Model = boost::concepts::VertexListGraphConcept<leda::GRAPH<int, int> >]' leda_graph_cc.cpp:21:5: instantiated from here ../../../boost/graph/graph_concepts.hpp:189:9: error: no matching function for call to 'vertices(leda::GRAPH<int, int>&)' ../../../boost/graph/graph_concepts.hpp:189:9: note: candidate is: ../../../boost/graph/graph_concepts.hpp:45:48: note: template<class T> typename T::ThereReallyIsNoMemberByThisNameInT boost::vertices(const T&) (among some further errors, but I'd like to ask just about this one now) Apparently it cannot find a vertices() function: ../../../boost/graph/graph_concepts.hpp:189:9: error: no matching function for call to 'vertices(leda::GRAPH<int, int>&)' But there is one in leda_graph.hpp: template <class vtype, class etype> inline std::pair< typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator, typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator > vertices(const leda::GRAPH<vtype,etype>& g) { typedef typename graph_traits< leda::GRAPH<vtype,etype> >::vertex_iterator Iter; return std::make_pair( Iter(g.first_node(),&g), Iter(0,&g) ); } So, can someone enlighten me why it isn't found? Has it something to do with #ifdef BOOST_VECTOR_AS_GRAPH_GRAPH_ADL_HACK // dwa 2003/7/11 -- This clearly shouldn't be necessary, but if // you want to use vector_as_graph, it is! I'm sure the graph // library leaves these out all over the place. Probably a // redesign involving specializing a template with a static // member function is in order :( using boost::vertices; #endif ? Best regards, Jens

2 8

Many Boost.Test unit tests fail
by Barend Gehrels 01 Jan '12

01 Jan '12

Hi, Since today or yesterday, many regression tests fail. http://www.boost.org/development/tests/trunk/developer/summary.html I believe on platforms that are recently added, at last on platforms that were not present at December 17. 1) on clang/darwin, message ../boost/test/tools/assertion.hpp:278:21: error: no member named 'forward' in namespace 'std' 2) on clang/linux, message /usr/bin/ld: skipping incompatible /sierra/Sntools/extras/compilers/gcc-4.4.4/lib/libstdc++.so when searching for -lstdc++ We have these errors in Boost.Geometry but I also noticed them in many other libraries. Regards, Barend

2 2

[filesystem] path thread safety fix impact on POSIX systems
by Beman Dawes 01 Jan '12

01 Jan '12

Class path locale initialization has suffered from a data race for several releases. See https://svn.boost.org/trac/boost/ticket/6320 for an example of code that suffers as a result. The problem was introduced when locale initialization was changed from namespace scope initialization to function scope initialization. For Windows and Mac OS X, the fix is simply to change back to namespace scope initialization. For non-BSD based POSIX systems such as Linux, the problem is more complex. These system need std::locale(""), "the locale-specific native environment". Considerations: * std::locale("") will throw if environmental variables are configured incorrectly. For example, setting LANG=foo on my Ubuntu system causes std::locale("") to throw. * std::locale("") is only needed if conversions between wide and narrow character paths occur in the program, so it would be unfortunate to have programs throw that don't actually do any such conversion. * With GCC, std::locale("") at namespace scope will throw before main() has started! That prevents catching the exception in the user code, and was what led to moving the initialization to a function scope static. Initialization as a function scope static also meant that the exception only occurred if user code actually performed wide - narrow conversions. I can see two possible fixes: (A) Use function scope locale initialization, using boost/detail/lightweight_mutex.hpp to prevent data races. (B) Use namespace scope locale initialization, defaulting the codecvt facet to UTF-8 if std::locale("") throws. The advantage of (B) is that path always initializes without throwing, and that's what users seem to expect. The initialization is correct for all those whose environments are configured correctly, and for those uses who want UTF-8 even if their environments are misconfigured. The POSIX users who prefer an exception on a misconfigured environment can always add a std::locale("") at the start of main(). Comments or opinions? --Beman

4 6