- Boost - lists.boost.org

[context] update
by Oliver Kowalke 17 Nov '11

17 Nov '11

Hi, a new updated version is available. src: http://github.com/olk/boost.context docu: http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html next step mini-review? so long, Oliver

1 0

Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Jeffrey Lee Hellrung, Jr. 17 Nov '11

17 Nov '11

Hi all, It is time! The review of Lorenzo Caminiti's proposed Boost.Local library begins tomorrow, ***November 10, 2011***, and ends on ***November 19, 2011***. Boost.Local implements local functions, local blocks, and local exits for the C++ programming language. It allows one to define a function at any declarative scope, including function scope; bind variables from the enclosing scope; and pass this function to templated STL-style algorithms. Please see the Introduction of the documentation for a longer but still brief overview. -------- The code and documentation are available from the Boost sandbox ( https://svn.boost.org/svn/boost/sandbox/) https://svn.boost.org/svn/boost/sandbox/local/ [everything] https://svn.boost.org/svn/boost/sandbox/local/boost/ [code] https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.htm… -------- Please state clearly whether you think this library should be accepted as a Boost library. Other questions you may want to consider: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Please also consider the following issues and proposals specific to Boost.Local. Your opinion is welcome on any or all of these. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? - Lorenzo is proposing to add boost::local::function::overload to Boost.Function as boost::function::overload. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… -------- Lastly, please note that Boost.Local has included a copy of the Variadic Macro Data (VMD) library in boost/detail/preprocessor/variadic_macro_data. Since then, VMD has been modified and integrated into Boost.Preprocessor. After the review has concluded, Lorenzo will remove this local copy of the VMD library and replace its usage within Boost.Local with the Boost.Preprocessor variadic extensions. -------- Thanks in advance to all who participate in the review discussion; I'm looking forward to it! - Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)

7 21

Alternative implementation for BOOST_PP_VARIADIC_SIZE
by Gennadiy Rozental 17 Nov '11

17 Nov '11

Hi, Current implementation of subject macro have a very serious shortcoming - it does not work for empty __VA_ARGS__. After googling around a bit for some ideas I came up with the following alternative: #include <boost/preprocessor/arithmetic/mul.hpp> #include <boost/preprocessor/arithmetic/sub.hpp> #include <boost/preprocessor/punctuation/comma.hpp> #define MY_VA_ARG_N( \ _1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \ _11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \ _21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \ _31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \ _41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \ _51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \ _61,_62,_63, N, ...) N #define MY_VA_RSEQ_N() \ 63,62,61,60, \ 59,58,57,56,55,54,53,52,51,50, \ 49,48,47,46,45,44,43,42,41,40, \ 39,38,37,36,35,34,33,32,31,30, \ 29,28,27,26,25,24,23,22,21,20, \ 19,18,17,16,15,14,13,12,11,10, \ 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 #define MY_DO_VA_NARG2(...) MY_VA_ARG_N __VA_ARGS__ #define MY_DO_VA_NARG(...) MY_DO_VA_NARG2(( __VA_ARGS__ )) // this version produces incorrect value (1) for empty __VA_ARGS__ #define MY_VA_NARG_(...) MY_DO_VA_NARG(__VA_ARGS__, MY_VA_RSEQ_N()) // this version fixes it #define MY_VA_NARG(...) BOOST_PP_SUB( BOOST_PP_MUL( MY_VA_NARG_( __VA_ARGS__ ), 2 ), MY_VA_NARG_( BOOST_PP_COMMA __VA_ARGS__ () ) ) This version work for zero sized __VA_ARGS__ and also works for MSVC-9,10 , gcc-4.1 gcc 3.2 (did not test with other compilers). Does it make sense to improve trunk version? Regards, Gennadiy

7 39

[1.48.0] Can't build any PDF docs
by John Maddock 16 Nov '11

16 Nov '11

I'm trying to build the PDF docs for 1.48 but all attempts to build PDF's on both Trunk and release branches fails with errors such as: bjam pdf M:/data/boost/trunk/tools/build/v2/tools\boostbook.jam:649: in object(boostbook-generator)(a)49.run from module object(boostbook-generator)@49 error: Cannot build documentation type 'pdf' M:/data/boost/trunk/tools/build/v2/build\generators.jam:1004: in try-one-generator-really from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1066: in try-one-generator from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1282: in construct-really from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1366: in generators.construct from module generators M:/data/boost/trunk/tools/build/v2/build\targets.jam:1495: in construct from module object(typed-target)@776 M:/data/boost/trunk/tools/build/v2/build\targets.jam:1297: in object(typed-target)(a)776.generate from module object(typed-target)@776 M:/data/boost/trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@782 M:/data/boost/trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)782.generate from module object(main-target)@782 M:/data/boost/trunk/tools/build/v2/build\targets.jam:258: in object(project-target)(a)772.generate from module object(project-target)@772 M:/data/boost/trunk/tools/build/v2\build-system.jam:736: in load from module build-system M:\data\boost\trunk\tools\build\v2/kernel\modules.jam:283: in import from module modules M:\data\boost\trunk\tools\build\v2\kernel\bootstrap.jam:142: in boost-build from module M:\data\boost\trunk\boost-build.jam:17: in module scope from module Nothing has changed in my user-config.jam, and I've updated to the latest bjam executable. Any ideas on what broke? Thanks, John.

2 3

Boost.Random.uniform_01 gives different number sequence in Boost 1.37 and Boost 1.45
by Martin.Sovik＠Emerson.com 16 Nov '11

16 Nov '11

Hi. It seems that uniform_01 generates different number sequences in version 1.37 and 1.45 Is this intentional, or is it a bug? This short program #include <iostream> #include "boost/random/mersenne_twister.hpp" #include "boost/random/uniform_01.hpp" int main() { boost::mt19937 random_generator(4315); boost::uniform_01< boost::mt19937, double > uniform_generator(random_generator); std::cout<<"Generating uniform distribution using Boost 1.45"<<std::endl; for (int i=0; i<10;++i) { std::cout<<uniform_generator()<<std::endl; } return 0; } Compiled with the two versions, gives the respective output: D:\dev\test_bed>uniform_dist_boost_1_37 Generating uniform distribution using Boost 1.37 0.239136 0.920749 0.889477 0.208172 0.169688 0.636659 0.78322 0.915117 0.25697 0.358218 D:\dev\\test_bed>uniform_dist_boost_1_45 Generating uniform distribution using Boost 1.45 0.306389 0.511291 0.496429 0.156168 0.910315 0.644836 0.331514 0.558632 0.723934 0.998796 As far as I can tell, Boost.mt19937 gives the same number sequence in both cases, but the output from Boost.uniform_01 differs. This topic has been briefly touched in the thread [boost] Random numbers question<154235.php> Anant Rao (2009-07-24 18:47:31) Where it seems like Rao got different numbers even between Boost 1.38 and Boost 1.39 We use Boost 1.37 in the previous release of our software, and Boost 1.45 in the current, and we have received a bug report from one of our clients that our current release has different behaviour. Is there any way to fix this, other than use the 1.37 version of Boost.uniform_01? Thanks, Martin Søvik

2 1

Re: [boost] [1.48.0] Release candidates available
by Tom Kent 16 Nov '11

16 Nov '11

> Release candidate files for 1.48.0 are available at http://boost.cowic.de/rc/ > > md5sum on the originals: > > 7dd95e71c43ddd35997d9f2346e7f567 *boost_1_48_0.7z > d1e9a7a7f532bb031a3c175d86688d95 *boost_1_48_0.tar.bz2 > 313a11e97eb56eb7efd18325354631be *boost_1_48_0.tar.gz > b08fda829eec96b4f1071ce2ea6831f5 *boost_1_48_0.zip > > 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 On a windows 7 - 32 bit VM, I built: msvc-8.0 msvc-8.0 - address-model=64 msvc-9.0 msvc-9.0 - address-model=64 msvc-10.0 msvc-10.0 - address-model=64 All builds were successful. I was able to smoothly link and run with the binaries on windows 7 32 or 64 (depending on the library build). Tom Kent

1 0

[program_options] Improving error text in exceptions
by Leo Goodstadt 16 Nov '11

16 Nov '11

On 15 November 2011 09:08, Vladimir Prus <vladimir(a)codesourcery.com wrote: > > Leo Goodstadt wrote: > > I would very much like to make the error messages in program_options > > exceptions more consistent and informative. > > I've looked over the error messages you have proposed, and I think it's > an overall improvement. I would appreciate patch to make this change. > Thanks! Cool. Will do that. The error messages meant for programmers I shall leave alone. This exercise is so tedious that I doubt anyone else is going to do more than tinker with the message text so I am keen to do an exhaustive job. As I mentioned, for command line messages, <option '--foo_bar' is ambiguous> seems much clearer than than <option 'foo_bar' is ambiguous>. However, it would be inappropriate to add "--" to config file and dos style options. The easiest thing would be to add a "prefix" parameter to the set_option_name() functions in errors.hpp These are called inside store() in variables_map.cpp. To add "--" or "/" prefixes as appropriate, is it sufficient to look at basic_option::original_tokens and basic_option::string_key? A) Use no prefix if original_tokens[0] is unprefixed, B) Use the parsed prefix (original_tokens[0]) if basic_option::string_key.length() = 1 C) Prefer "--" for long option names The same logic would apply to 1) exceptions thrown from cmdline::finish_option() in cmdline.cpp 2) options_description::find() (in options_description.cpp) called from store() (in variables_map.cpp) 3) options_description::find_nothrow() (in options_description.cpp) called from cmdline::run(), cmdline::finish_option(), parse_short_option(), and parse_disguised_long_option() (in cmdline.cpp) (Despite its name, find_nothrow() can throw()!) The difficult case is supporting the correct prefix for "required_option" in variables_map::notify() (variables_map.cpp). I propose that where missing options can be specified in both configuration file and on the command line, the command line should take precedence, and "--option_name" displayed in the error message. To support this, "basic_parsed_options" needs an extra prefix field, which would be set appropriately by basic_command_line_parser<charT>::run(). Does this make sense? Thanks, Leo -- Leo Goodstadt University of Oxford, UK

2 1

[1.48.0] Release candidates available
by Beman Dawes 16 Nov '11

16 Nov '11

Release candidate files for 1.48.0 are available at http://boost.cowic.de/rc/ md5sum on the originals: 7dd95e71c43ddd35997d9f2346e7f567 *boost_1_48_0.7z d1e9a7a7f532bb031a3c175d86688d95 *boost_1_48_0.tar.bz2 313a11e97eb56eb7efd18325354631be *boost_1_48_0.tar.gz b08fda829eec96b4f1071ce2ea6831f5 *boost_1_48_0.zip 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

13 17

Re: [boost] Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

> > One suggestion for the future, although I am not sure how useful it would > > turn out in practice is to have something like local expression, or even > > not necessarily a local one. This would be a function whose body consists > > of a single expression. The benefit you get is that the programmer does not > > need to specify a return type for it (you can use BOOST_TYPEOF for that), > > or doesn't even have to type keyword 'return', but this may be too much off > > topic. > Can you clarify with an example? In C++11 lambdas do not require specifying the return type, provided that the body of the function is a single return statement: because it is easy to deduce the type from such single return statement. Similarly, for Boost.Local if a function body consists of a single return statement you could (I guess) provide a more simple syntax. Instead of BOOST_TYPEOF(sum) & BOOST_LOCAL_FUNCTION_PARAMS( double num, const bind factor, bind& sum ) { return sum += factor * num; } BOOST_LOCAL_FUNCTION_NAME(add); I could write: BOOST_LOCAL_EXPRESSION_PARAMS( double num, const bind factor, bind& sum ) BOOST_LOCAL_EXPRESSION_END( add, sum += factor * num ); You save me typing the return type and 'return' keyword. But now that I have written it down I do not think it is particularly useful. > I think in a nutshell the conclusion (which I will detail in the rest > of my comments below) was that Boost.Local is handy but on compilers > with C++11 lambdas you'd just use lambdas. At the same time, > Boost.Local allows you to write local functions that work also on > C++03 compilers and that have the same compile-time and run-time > performances of lambdas on C++11 compilers. So the /main/ audience > would be someone (like myself) that wants to do local function stuff > and expects lambda-like performances on C++11 but also has to deal > with C++03 compilers. There are other benefits like const& binding > which is not supported by C++11 lambdas (so how can I bind by const a > variable that has a very expensive copy constructor using C++11 > lambdas?) and improve scope exit (i.e., local exit) but these other > benefits are probably minor in the general domain (they can be very > important or even essential is a specific and narrow domain like > Contract Programming but not critical in the general case). OK Lorenzo, I am convinced. Can we trade? I will vote 'yes', and you will add a motivation section in the documentation which will stress that the primary motivation of the library is to provide a uniform (in terms of syntax) support for local functions: fast and 'native' for C++11 compilers, and acceptable (using tricks) in older compilers. The library can be used directly or be a foundation for higher level libraries like Boost.Concept. Review Managers, I am not really trading, I vote YES for the Boost.Local and just request the motivation section in the documentation. I think the situation of Boost.Local is similar to that of Boost.Move, and the latter was accepted into Boost. Also, having a library in Boost whose primary purpose is to serve as the foundation for other Boost libraries is not a precedent (I mean Boost.Proto and now Boost.Context). Regards, &rzej

3 2

Re: [boost] Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

Just one more thought. I was not participating in the design discussion for Boost.Local when it was probably a better time to mention this. So I am just mentioning it for reference. Functions that take parameters and bind existing objects are called closures: http://en.wikipedia.org/wiki/Closure_%28computer_science%29.<http://en.wikipedia.org/wiki/Closure_%28computer_science%29> This could have been an alternative name for BOOST_LOCAL_FUNCTION: BOOST_SCOPE_CLOSURE... Regards, &rzej

2 1