- Boost - lists.boost.org

[quickbook] template vs block vs phrase issues
by Andreas Pokorny 09 Dec '12

09 Dec '12

Hi, I use quickbook to write software design documentation targeting pdf. We now introduce a requirements tracking system that includes both source code and design documents. To describe or refer to requirements in docbook docments special xml markup is needed. I.e. something like <reqfooo><status>approved</status><version>1</version><id>DoOnlyNeededStuff</id><description></description></regfoo>. Since I do not want to write XML I added quickbook templates: [template reqfoo[id contents]'''<reqcfoo><id>'''[id]'''</id>'''[contents]'''</reqfoo>'''] [template sdesc[contents]'''<shortdesc>'''[contents]'''</shortdesc>'''] [template verification[contents]'''<verifycrit>'''[contents]'''</verifycrit>'''] [template source[contents]'''<source>'''[contents]'''</source>'''] [template usecase[contents]'''<usecase>'''[contents]'''</usecase>'''] [template status[contents]'''<status>'''[contents]'''</status>'''] [template version[contents]'''<version>'''[contents]'''</version>'''] and finally: [template desc[contents]'''<description>'''[contents] '''</description>'''] Now I want to use block elements inside the contents parameter of desc. Is there any way to achieve that? The only thing I can think of is: [template desc[]'''<description>'''] [template enddesc[]'''</description>'''] But then quickbook is just as good as xml! I tried to make desc a block level template by adding a line break at different positions, but then I get broken xml code, since para tags are spread around <description> regards Andreas

2 5

[Git] Modularizing Boost libraries with sublibs
by Daniel Pfeifer 09 Dec '12

09 Dec '12

While adding Boost.ODEint to the modularization manifest, I realized some inconsistencies about sublibs. The directories in "libs" usually contain one library each. In this case, we move the content to a dedicated Git repository. Some directories however (algorithm, numeric) host multiple libraries. How should we treat them? Move each one to a dedicated Git repository, or leave them grouped together? What's currently inconsistent, is that "numeric" is split into individual repositories, while "algorithm" is not. Further, I saw that the Git submodules of numeric's sublibraries are generated in "libs" rather than "libs/numeric", which is wrong. However, before I fix it, we need to decide whether these individual submodules should be individual or not. Opinions? Cheers, Daniel

4 5

Re: [boost] [Git] tools/wave missing (was: Documentation for Git and Modular Boost conversion)
by Hartmut Kaiser 09 Dec '12

09 Dec '12

> On Fri, Dec 7, 2012 at 3:42 PM, Eric Niebler <eric(a)boostpro.com> wrote: > > On 12/7/2012 11:44 AM, Oliver Kowalke wrote: > > >> Do I have to clone an additional submodule (which is not mentioned in > >> the docu)? > > > > Beman's docs appear to lack instructions for how to clone the > > super-project and initialize the sub-modules. That would be a nice > > addition. I don't know the steps and can't find them ATM, but I know > > it's documented *somewhere*. Beman? > > Just added: https://svn.boost.org/trac/boost/wiki/TryModBoost > > The original instructions were buried in a C++Now presentation slide. When I follow those steps as far as I can see everything looks fine except for tools/wave, which is missing. Is that intentional? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > > Thanks, > > --Beman > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 2

[Smart Pointers]
by Rahul Sr 09 Dec '12

09 Dec '12

Hi All, This is my first post though so please bear with my sentences. I have used scoped_ptr but this is too tied with new/delete semantics i.e. can't use it with pointers which gets allocated from specialized memory area. class AManager { public: A * allocate(); void deallocate(A * p); }; class A { ..... }; This specially happens when I use scoped pointer for C like pointers/allocator: Can I modify scoped pointer to have release semantics which is user defined: template<typename T> class DefaultReleasePolicy { static void releaseA(T * p) { delete p; } }; class ReleaseAPolicy { static void releaseA(A * p) { AManager::getInstance()->deallocate(p); } }; template<typename T,typemame ReleasePolicy = DefaultReleasePolicy<T> > class ScopedPtrModified { ~ScopedPtrModified() { ReleasePolicy::release(m_ptr); } }; Is this fine? Let me know your thoughts. Regards, Rahul

3 3

[odeint] Request to merge odeint into release branch
by Karsten Ahnert 09 Dec '12

09 Dec '12

I would like to ask for permission to merge odeint into the release branch. There are currently four failures in the regression tests. Two have already been fixed. The other two originate from the build time out of 180 seconds. These two tests will often require longer build times, since they heavily use Boost.Fusion, Boost.Units and Boost.MPL.

2 5

[multiprecision] Request permision to merge to release.
by John Maddock 09 Dec '12

09 Dec '12

I'd like to ask permission to merge the multiprecision lib to release. Note that as things stand I'm still chasing down test failures, but these are now mostly down to: * Things that work locally, but the testers haven't cycled yet. * 300s timeouts - mostly from the intel compiler :-( Aside: in an effort to reduce the number of timeouts, I've basically gutted some of the tests when the compiler is Intel, and I think I have all the build times under 20s on my Linux box, yet I'm still getting 300s timeouts on some tester machines, either those machines are seriously underpowered or I'm missing something here :-( Cheers, John.

3 5

[smart ptr] [shared] suggestion: single pointer in object returned from make_shared
by Julian Gonggrijp 09 Dec '12

09 Dec '12

Dear Smart Ptr maintainer(s), I recently learned that boost::make_shared allocates the space for the pointee and the reference counter in one go. It makes a lot of sense, and I might have suggested it if it wasn't already the case. Now I'm assuming that a shared_ptr stores two raw pointers internally, one to the pointee and one to the counter. I guess that would be necessary in the "normal" case where the pointee and the counter are allocated separately. Now in the case where the shared_ptr is created by make_shared, ideally you'd need to store only one raw pointer because pointee and counter reside in the same memory object. That would be the finishing touch to a nonintrusive smart pointer that really performs like an intrusive one. To me such a thing seems highly desirable. I realise this would require a new implementation of the shared pointer. Could this somehow be made to cooperate or at least coexist with the old shared_pointer? Would it perhaps even be an option to deprecate the old shared_pointer in order to entirely replace it by the new version in the future? I'll be most interested to read your comments on this idea. -Julian

1 0

Boost.Test updates in trunk: need for (mini) review?
by Gennadiy Rozenal 09 Dec '12

09 Dec '12

Hi, It's been a long while since I merged any changes into boost release and by now there are whole bunch of new features there. Some are small, but some others are big ones such that they can change the way people use the library. I'd like to list them here (excluding bug fixes and removal of deprecated interfaces) and ask what should we do with these. Specifically let me know if you think these require some kind of (mini) review from community, but any other comments are welcome as well. So here we go: I. New testing tool BOOST_CHECKA This tool is based on excellent idea from Kevlin Henney. I chose the name CHECKA for this tool due to the lack of better name, but I am open to suggestions. This testing tool capable of replacing whole bunch of existing other tools like BOOST_CHECK_EQUAL, BOOST_CHECK_GT etc. Usage is the most natural you can wish for: BOOST_CHECKA( var1 - var2 >= 12 ); And the output will include as much information as we can get: error: in "foo": check var1 - var2 >= 12 failed [23-15<12] II. New "data driven test case" subsystem New data driven test case subsystem represent a generalization of parameterized test case and test case template and eventually will replace both. The idea is to allow user to specify an arbitrary (monomorphic or polymorphic) set of samples and run a test case on each of the samples. Samples can have different arity, thus you can have test cases with multiple parameters of different types. For now we support following dataset kinds (aside of generators none of dataset constructions routines performs *any* copying): a) singleton - dataset constructed out of single sample data::make(10) - singleton dataset with integer sample data::make("qwerty") - singleton dataset with string sample b) array - dataset constructed out of C array int a[] = {1,2,3,4,5,6}; data::make(a) - dataset with 6 integer values c) collection - dataset constructed out of C++ forward iterable collection std::vector<double> v{1.2, 2.3, 3.4, 5.6 }; data::make(v) - dataset with 6 double values d) join - dataset constructed by joining 2 datasets of the same type int a[] = {1,2,3}; int b[] = {7,8,9}; data::make(a) + data::make(b) - dataset with 6 integer values e) zip - dataset constructed by zipping 2 datasets of the same size, but not necessarily the same type This dataset has an arity which is sum of argument dataset arities. int a[] = {1,2,3}; char* b[] = {"qwe", "asd", "zxc"}; data::make(a) ^ data::make(b) dataset with 3 samples which are pairs of int and char*. f) grid - dataset constructed by "multiplying" 2 datasets of the same different sizes and types type This dataset has an arity which is sum of argument dataset arities. int a[] = {1,2,3}; char* b[] = {"qwe", "asd"}; double c[] = {1.1, 2.2}; data::make(a) * data::make(b) * data::make(c) dataset with 12 samples which are tuples of int and char* and double. g) xrange generator dataset which produes samples in some range data::xrange( 0., 3., 0.4 ) - dataset with 8 double samples data::xrange<int>((data::begin=9, data::end=15)) - dataset with 6 int samples data::xrange( 1., 7.5 ) - dataset with 7 double samples data::xrange( 5, 0, -1 ) - dataset with 5 int samples h) random - generator dataset with unlimited number of random samples data::random(data::distribution = std::normal_distribution<>(5.,2)) dataset with random double numbers following specified distribution data::random(( data::engine = std::minstd_rand(), data::distribution = std::discrete_distribution<>(), data::seed = 20UL )); dataset with random int numbers following specified distribution While all this interfaces can be used by itself to build complex datasets with various purposes, primary use case it was developped for is new data driven test case interface: BOOST_DATA_TEST_CASE( test_name, dataset, parameter_names... ) Here are couple examples: int samples1[] = {1,2,3}; BOOST_DATA_TEST_CASE( t1, samples1, sample ) { BOOST_CHECKA( foo(sample) > 0 ); } Above test case is going to be executed 3 times with different sample values char* strs[] = {"qwe", "asd", "zxc", "mkl" }; BOOST_DATA_TEST_CASE( t1, data::xrange(4) ^ strs ^ data::random(), intval, str, dblval ) { MyObj obj( dblval, str ); BOOST_CHECKA( obj.goo() == intval ); } Above test case will be executed 4 times with different values of parameters intval, str, and dblval. Polymorphic datasets are still being developed, but should appear soon(ish). III. Auto-registered test unit decorators. Previously is was not possible and/or convenient to assign attributes to the automatically registered test units. To alleviate this I've introduced a notion of test unit decorator. These can be "attached" to any test unit similarly to like it is done in other languages Following decorators already implemented: label - adds labels to a test unit expected_failures - set expected failures for a test unit timeout - sets timeout for a test unit description - sets a test unit description depends_on - sets a test unit dependency enable_if/disable_if - facilitates a test unit status change fixture - assigns fixture to a test units Test unit description is new test unit attribute, which is reported by new list_content command line argument described below. Usage of labels covered below as well. enable_if/disable_if allow new, much more flexible test management. By adding enable_if/disable_if decorators to the test unit you can conditionally select which test units to run at construction time based on some compile time or run-time parameters. And we finally we have suite level fixtures which are set by attaching fixture decorator to a test suite (suite level fixtures executed once per test suite). Attachment of decorator is facilitated by using of BOOST_TEST_DECORATOR. Note that you can use any of '+', '-', '*' symbols to attach decorator (and any number of '*'): BOOST_TEST_DECORATOR( + unittest::fixture<suite_fixture>() ) BOOST_AUTO_TEST_SUITE( my_suite1 ) { } BOOST_TEST_DECORATOR( - unittest::timeout( 100 ) - unittest::expected_failures( 1 ) - unittest::enable_if( 100 < 50 ) ) BOOST_AUTO_TEST_CASE( my_test5 ) BOOST_TEST_DECORATOR( **** unittest::label( "L3" ) **** unittest::description( "suite description" ) **** unittest::depends_on( "my_suite2/my_test7" ) ) BOOST_AUTO_TEST_CASE( my_test11 ) IV Support for "run by label" plus more improvements for filtered runs Previously you only had an ability to filter test unit to execute by name. Now you can attach labels to test units and create collections to run which are located in arbitrary positions in test tree. For example you can have special label for performance test cases, which is attached to all test units which are responsible for testing performance of your various components. Or you might want to collect exception safety tests etc. To filter test units by level you still use --run_test CLA. Labels are dented by @prefix: test.exe --run=@performance You can now repeat --run_test argument to specify multiple conditions: test.exe --run=@performance,@exception_safety --run=prod/subsystem2 In addition run by name/label now recognizes dependencies. So if test unit A depends on test unit B and test unit B is disabled/is not part of current run test unit A will not run as well. Finally you now have an ability to specify "negative" conditions, by prefixing name or label with ! test.exe --run=!@performance This will run all test units which are not labeled with "performance". V. Support for failure context In many scenarios it is desirable to specify an additional information to a failure, but you do not need to see it if run is successful. Thus using regular print statements is undesirable. This becomes especially important when you develop common routine, which performs your testing and invoke it from multiple test units. In this case failure location is no help at all. To alleviate this problem two new tools are introduced: BOOST_TEST_INFO BOOST_TEST_CONTEXT BOOST_TEST_INFO attaches context to next assertion which is executed. For example: BOOST_TEST_INFO( "a=" << a ); BOOST_CHECKA( foo(a) == 0 ); BOOST_CHECK_CONTEXT attaches context to all assertions within a scope: BOOST_CHECK_CONTEXT( "Starting test foo from subset " << ss ) { BOOST_CHECKA( foo(ss, a) == 1 ); BOOST_CHECKA( foo(ss, b) == 2 ); } VI. Two new command line arguments: list_context, wait_for_debugger Using list_context you can see a full or partial test tree of your test module. wait_for_debugger allows to force test module to wait till you attach debugger. VII. Colored output. Using new CLA --color_output you can turn on colored output for error and information messages VIII New production testing tools interface introduced This feature was covered in details in my presentation in BoostCon 2010. The gist if this is an ability to use Boost.Test testing tools interfaces in production (nothing to do with testing) code. User supplied implementation is plugged in IX. Number of smaller improvements: * Notion of framework shutdown. Allows to eliminate some fake memory leaks * Added checkpoints at fixture entry points, test case entry point and test case exit point for auto registered test cases * New FPE portable interfaces introduced and FPE handling is separated from system errors handling. You can detect FPE even if catch_system_error is false * Added an ability to erase registered exception translator * execution_monitor: new interface vexecute - to be used to monitor nullary functions with no result values * test_tree_visitor interface extended to facilitate visitors applying the same action to all test units * execution_monitor use typeid to report "real" exception type if possible. * New ability to redirect leaks report into a file Thank you for your time, Gennadiy

21 66

[config] Macro for null pointer
by Edward Diener 08 Dec '12

08 Dec '12

I have found something like this to be helpful, when working with multiple compilers: #include <boost/config.hpp> #if defined(BOOST_NO_NULLPTR) #define BOOST_XXX_NULLPTR 0 #else #define BOOST_XXX_NULLPTR nullptr #endif where XXX is some local name for my own use. And then use BOOST_XXX_NULLPTR in places where a null pointer is needed. Would this be a candidate for a BOOST_NULLPTR macro in the config library instead ? Edward Diener

16 63

Re: [boost] [boost-steering] Re: [Git] Documentation for Git and Modular Boost conversion
by Brian Wood 08 Dec '12

08 Dec '12

Dave Abrahams: > Boost is making this transition. It *will* cause some disruption. It > will also make things easier for some people. I'm glad to hear this effort is continuing. > IMO we should not burden this move, which is supposed to > make it easier and more efficient overall for Boost to operate, > with any unnecessary obligations. That sounds harsh, but I guess that's the way the cookie crumbles. -- Brian Wood Ebenezer Enterprises -- so far G-d has helped us. http://webEbenezer.net

1 0