- Boost - lists.preview.boost.org

[graph][BGL][PBGL] Proposed patches
by bminano 15 Jan '14

15 Jan '14

Hi, I found two problems using the graph library, concretely using it in parallel. Swimming into the code I think I found possible solutions to that. I proposed two patches in boost Trac at tickets #9549 and #8250, but I had no response. I am afraid the tickets were not revised, so I think publishing here would be a good idea. Maybe the maintainers of the library want to apply that patches for future releases. I hope so, as I am working in a project that will select boost graph as a masterpiece of graph simulations. I the responsible wants to ask me about the bugs I'll be glad to answer. -- View this message in context: http://boost.2283326.n4.nabble.com/graph-BGL-PBGL-Proposed-patches-tp465789… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] GSoC 2014
by Christopher Kormanyos 15 Jan '14

15 Jan '14

> hi sir, > i m deepak, i want to apply for GSOC 2014 . i am good in c++, mathematics > and having proficient knowledge of algorithms. > i have a special interest for following boost libraries > - Boost.Math Generalized Hypergeometric Functions Well, that's a cool one for sure :-) Thank you for your interest, deepak. It's still a bit early in the game because we have not yet found an organization administrator. Nor have we formally applied as an organization for GSoC 2014. So keep an eye on the progress and base your actions accordingly. > Boost.Multiprecision > new data structures and algorithms I do not believe that we will be working on Multiprecision in this year's GSoC. Some of the things are already done, and others, quite honestly have too much novel research character for GSoC. This is an area for independent research at the moment. > i want to know if i could start early or work with boost trac or you tell me what to do As I mentioned, keep an eye on our progress. If Boost applies, and if Boost gets nominated for GSoC, then you may apply. It is a worldwide competition, so it always helps to apply early, ask questions on the board, write a good proposal, and generally do your best. Good luck. Chris. On Tuesday, January 14, 2014 8:45 PM, deepak goel <deepakgoel7514(a)gmail.com> wrote: On Monday, January 13, 2014 2:08:39 AM UTC+5:30, Christopher Kormanyos wrote: >> I have just added a page for GSoC 2014 here >> https://svn.boost.org/trac/ boost/wiki/SoC2014 > >Thank you Vicente. > >I have added "Boost.Math Generalized Hypergeometric Functions". > >Sincerely, Chris. > > > > > >On Sunday, January 12, 2014 6:45 PM, Vicente J. Botet Escriba <vicent...(a)wanadoo.fr> wrote: > >Le 12/01/14 18:20, Christopher Kormanyos a écrit : > >>> Deadline for registering as a mentoring organization for GSoC 2014 is 14 >>> Feb 2014. >>> Should we start collecting ideas? >> I believe we have several good ideas. We need to get moving. >> >> Does anyone know how to put up the skeleton of this kind >> of page? (Or can anyone point me in the right direction on >> how to do it?) >> >> https://svn.boost.org/trac/ boost/wiki/SoC2013 >> >> The hard part, I believe, will be finding one or more org admins. >> The guys did a great job last year, and set the bar pretty high. >> >> * I can probably mentor a student. >> * I can help collecting and writing the ideas on SVN trac. >> * I could also help writing the GSoC 2014 proposal and with recruiting. >> >> But org admin would potentially be too much of a commitment for me. >> >> Is anyone interested in being org admin for GSoC 2014? >> >Hi, > >I have just added a page for GSoC 2014 here >https://svn.boost.org/trac/ boost/wiki/SoC2014. > >Be free to add your projects and ideas. >Vicente > > hi sir, i m deepak, i want to apply for GSOC 2014 . i am good in c++, mathematics and having proficient knowledge of algorithms. i have a special interest for following boost libraries - Boost.Math Generalized Hypergeometric Functions Boost.Multiprecision new data structures and algorithms i want to know if i could start early or work with boost trac or you tell me what to do ______________________________ _________________ >Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost > > >______________________________ _________________ >Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost >

2 1

Regression test results starting to become available
by Beman Dawes 15 Jan '14

15 Jan '14

http://beta.boost.org/development/tests/master/developer/summary.html http://beta.boost.org/development/tests/develop/developer/summary.html Only a few of the testers have cycled. Some testers are only reporting results for 15 or so libraries. That's an artifact of getting started; these testers cycle the full tests will appear. --Beman

5 6

[git] annotated SVN synchronization for boost.test (example only)
by Peter A. Bigot 15 Jan '14

15 Jan '14

Below is an annotated sequence of (bash) command-line git operations that I used in a local copy of Boost.Test to understand what was happening in it, with no intention of proposing this be what the maintainers actually do with the module. Boost.Test is particularly interesting because master has been essentially unchanged for four years, while there are significant modifications pending in develop. A few of the changes on master make the SVN synchronization step tricky. People who want to hone their git-fu might find it workwhile to follow these steps in a local workspace to see how they work. I make no claim that they're the only way the same goal could be reached. I also have not used this for further development, so there the resulting structure may be flawed or contrary to strict git-flow expectations. WARNING: DO NOT paste the entire sequence into a shell window: at a couple of places you must manually do what the comment says (e.g., edit the contents of files to resolve conflicts) in order to reach a successful state. # Revert to a clean state where local branches match the origin, and the # working branches from any previous run of the script have been # removed. git fetch origin git checkout master git reset --hard origin/master git checkout develop git reset --hard origin/develop git branch -D synch/master synch/develop basis # git-merge-base identifies the commit to be used when merging things. # We're looking for something better, so no need to go beyond that one. MERGE_BASE=$(git merge-base develop master) # 635b1e38dd643af264c2ea8f0ba08dfb58337e37 echo ${MERGE_BASE} # Examine the history along master and develop, finding the most recent # SVN revision merged from develop into master. This only works if all # previous SVN revisions were also merged; if only select ones were # merged, it's probably best to skip them and keep looking. For # example, master on Boost.Test merged 81913, 63640, 62426, and a couple # others, but the last version that incorporated most prior fixes was # 57993 merged in ${MST_MP_SHA1}. git log ${MERGE_BASE}..master MST_MP_SHA1=2e4f64197956ccb94b24be4ed32abf25ee4b9dd1 # Now find the develop commit that most recently preceded that one in # SVN history. Basically, this is reviewing the log of differences # for the last commit with a SVN revision less than the one selected in # the previous step. BEWARE: If the revision you picked above doesn't # correspond to a develop branch change (e.g., if you picked 81913 which # didn't go into develop until 82756) you will create pain for yourself. git log ${MERGE_BASE}..develop # Here it's commit 57864 in ${DEV_MP_SHA1} DEV_MP_SHA1=fd8d9b3e4e4ab9656b0d880e8c519eabd134638a # Now take a look at what's different between those versions. That's # what'll get lost in a "-s ours" merge if it subsequently appeared in # develop. git diff ${DEV_MP_SHA1}..${MST_MP_SHA1} # There's some whitespace differences, some casts and error messages, # file permission changes, and two small changes from r81913 that we'll # talk about later. # Here's where my technique differs: You could do an "-s ours" merge # from the selected develop commit into master's HEAD as recommended at # https://svn.boost.org/trac/boost/wiki/StartModMaint#Firstpost-svnconversion… # but if you do you might lose cherry-pick commits on master that are # also on develop. Instead, we'll create a new merge point on master at # the synchronization point, and merge from develop. git checkout -b basis ${MST_MP_SHA1} git merge -s ours -m 'SVN merge basis preserving master' ${DEV_MP_SHA1} # Verify that the differences are the ones we accepted earlier: git diff basis..${DEV_MP_SHA1} # Now, let's do some cleanup, and get master and develop branches that # actually fork at the merge point, rather than simply assume the merge # point is identical. This indirectly helps manage the differences that # we threw away with "-s ours". git checkout -b synch/master master git rebase basis # This should show no differences, because we just inserted a commit # that records parentage but changes no content. git diff master synch/master # Do the same at develop. Here we're going to have to resolve any # conflicts between the selected merge point git checkout -b synch/develop develop git rebase basis # 66 patches in we hit one of the differences: git stat # (MANUAL STEP) There's whitespace at the end of build/Jamfile.v2. Edit # the file to remove the diff markers, stage the changes, and tell # rebase to continue. git add -u git rebase --continue # After 204 patches there's another. git stat # (MANUAL STEP) Here you'll see everything is clean except # include/boost/test/impl/framework.ipp. Search for <<<<<< and edit to # keep the one with the upper-case TUT_SUITE. git add -u git rebase --continue # And we're done. Now let's see what changed: git diff develop synch/develop # Some of the differences between master and develop at the SVN merge # point have gone away; these are the ones I suspect but have not # confirmed would have been lost had we merged to master's HEAD instead # of to the base version. A few changes remain that were in master but # not in develop. # You have a choice at this point. If the repository wasn't already # public, I'd reset master (develop) to synch/master (synch/develop) and # move on. But since they were public, merge them; keeps history, # and makes future actions cleaner. git checkout master git merge -m 'Merge in rebased master' synch/master git checkout develop git merge -m 'Merge in rebased develop' synch/develop # Finally, what would happen if we merged develop into master now? git checkout -b test master git merge develop # Very nearly a clean merge. See what's not staged: git stat -u | grep '^.[^ ]' # ## test # UU include/boost/test/utils/runtime/cla/parameter.hpp # UU include/boost/test/utils/runtime/env/variable.hpp # # Again, open the files and look for the diff markers: one uses m!=0 and # the other !!m. Which is right? Use git-blame: git blame origin/master include/boost/test/utils/runtime/cla/parameter.hpp # The master change came in 954d3ab6 which was SVN commit r81913 by # Vicente J. Botet Escriba. Show the change: git log -p 954d3ab6^! git blame origin/develop include/boost/test/utils/runtime/cla/parameter.hpp # The develop change came in 4f7fc06c which was SVN commit r82756 by # Gennadiy Rozental. Show the change: git log -p 4f7fc06c^! # Note that if, back when selecting the SVN merge point, we'd gone with # r81913 things would be completely bolluxed at this point since the # corresponding change didn't come from the develop branch. # (MANUAL STEP) It's Rozental's project, so pick the develop solution # (!!m). Then stage the changes and commit, editing the message to # indicate how you resolved the conflict. git add -u git commit

5 7

[any] Equality
by Bjorn Reese 15 Jan '14

15 Jan '14

I noticed that boost::any does not have an operator== for comparing two boost::any objects. Is this a deliberate choice? Currently I have to (1) compare the types, and (2) convert the values with any_cast (and probably catch bad_any_cast exceptions) and compare them.

4 4

[context] compile failure
by Jürgen Hunold 15 Jan '14

15 Jan '14

Hi Oliver, Boost.Context fails to compile since commit 5f52abd82fb6fb32d7d79575e48b3f26bfff6d27 Author: Oliver Kowalke <oliver.kowalke(a)gmx.de> Date: Thu Jan 9 17:39:59 2014 +0100 add support for 'combined' architeture on MacOS X with error message: - 32-bit : no - 64-bit : no error: at /ive/hunold/src/devel/boost/tools/build/src/kernel/modules.jam:107 error: Unable to find file or target named error: '/boost/architecture//combined' error: referred to from project at error: '/ive/hunold/src/devel/boost/libs/context/build' It seems that config/ is missing the combined.cpp needed for the architecture check. Could you please add it? Tip: Use git config --global status.showuntrackedfiles all to always show new file with "git status". This is from http://qt-project.org/wiki/Setting-up-Gerrit but maybe should be in our wiki,too. Thanks! Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 4

Re: [boost] Prefix Trie
by Arash Partow 14 Jan '14

14 Jan '14

On Wed, Jan 15, 2014, Michael Conlen wrote: > > I recently discovered that there seems to be a lack of good Prefix Tries in C++. blah blah blah. > I highly doubt your assertion. In fact I'd go so far as to say, the only language one can find decent-to-excellent implementations of the various algorithms is C++. eg: https://code.google.com/p/patl/

1 0

Adding cstdfloat.hpp - wheres the best place?
by John Maddock 14 Jan '14

14 Jan '14

Folks, Christopher Kormanyos has coded up a version of cstdfloat.hpp for Boost.Math: https://github.com/boostorg/math/blob/bernoulli-tgamma/include/boost/math/t… This header is proposed for C++14, and the C language folks are doing something similar: it provides similar functionality for floating point types that <cstdint> does for integer types: Typedefs: floatN_t float_leastN_t float_fastN_t floatmax_t Macros: BOOST_FLOATN_C(x) // floating point constant of width N. BOOST_FLOAT_N_MIN BOOST_FLOAT_N_MAX BOOST_FLOAT_FASTN_C(x) BOOST_FLOAT_LEASTN_MIN BOOST_FLOAT_FASTN_MIN BOOST_FLOAT_LEASTN_MAX BOOST_FLOAT_FASTN_MAX BOOST_FLOATMAX_C(x) BOOST_FLOATMAX_MIN BOOST_FLOATMAX_MAX Where N is one of 16, 32, 64, 128 and correspond to the IEEE half, single, double and quad types respectively. So... the question is where to best place this? Does anyone object if it goes under boost/cstdfloat.hpp to sit alongside cstdint.hpp? Where should it best be documented and tested? We can obviously add it under the Math lib, but is there a better more "discoverable" place? cstdint.hpp is under integer BTW so it can't go there ;-) Thanks in advance, John.

2 1

[TortoiseGit] New release fixes submodule problem bothering some Boosters
by Beman Dawes 14 Jan '14

14 Jan '14

TortoiseGit release 1.8.7.0 fixes the Submodule Update... crash that was one of the few problems that forced TortoiseGit users to switch to the command line. Thanks to the TortoiseGit folks for jumping on the Boost bug report immediately, and the libgit2 folks who in turn fixed a problem with their library. --Beman

1 0

The Community Maintenance Team proposal accepted
by Beman Dawes 14 Jan '14

14 Jan '14

The Steering Committee has voted to accept the Community Maintenance Team proposal, and Marshall Clow has volunteer to act as the team's fearless leader. See https://dl.dropboxusercontent.com/u/9897665/community-maintenance.htmlfor the actual proposal. Thanks to everyone who contributed ideas and discussion. I tried to capture contributors names in the Acknowledgements section of the proposal. Apologies if I missed anyone. --Beman

14 23

[git] nit in library release documentation
by Peter A. Bigot 14 Jan '14

14 Jan '14

At https://svn.boost.org/trac/boost/wiki/StartModMaint#Lightweightlibraryrelea… there is: git tag -a mylib-1.2.0 git push --tags mylib-1.2.0 # specific tag pushed to avoid pushing all local tags As discussed in a thread on module tagging, --tags should never be used with git push as it pushes all local tags to the remote repository (adding those that did not exist there). There are cases where you might want to do that, but for the specific situation of releasing a tagged library a sufficient and less risky command is: git push mylib-1.2.0 # specific tag pushed to avoid pushing all local tags Peter

2 1

Re: [boost] Is there interest in a collection of call stack utilities?
by Aurelian Melinte 14 Jan '14

14 Jan '14

Hello, To follow up on the discussion https://groups.google.com/forum/#!topic/boost-developers-archive/PSwTBEEe0Ao I was not clear if there is interest for it or not. I went ahead and the first cut of the code is now at https://github.com/melintea/Boost-Call_stack Please feel free to take a look and comment. Regards, Aurelian

6 7

Getting Started with Modular Boost Library Maintenance
by Gly Marvellou 14 Jan '14

14 Jan '14

1 0

Removing support for old compilers
by Joaquin M Lopez Munoz 14 Jan '14

14 Jan '14

Hi Stephen As part of your initiative of removing support for old compilers, are you building somewhere a change log in the form of either a list of compiler deficiencies or compiler versions no longer supported? I understand this should be inserted in a prominent place on the Boost 1.56 release notes and can serve as a reference for lib maintainers reviewing your patches (tracking changesets is harder and commit messages are not always completely illuminating). Thank you, Joaquín M López Muñoz Telefónica Digital

16 51

[Thread] Doc bug?
by Alexander Lamaison 14 Jan '14

14 Jan '14

The docs [1] for the `scoped_thread` and `strict_scoped_thread` says > "While thread call std::terminate() on the destructor is the thread is > joinable, strict_scoped_thread<> or scoped_thread<> join the thread if > joinable. Several other places on the page say something similar. I was under in the impression that Boost.Thread had toyed with adopting this behaviour to match `std::thread` but decided against it after complaints on this list. Am I wrong? [1] http://www.boost.org/doc/libs/1_55_0/doc/html/thread/ScopedThreads.html Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

3 3

[range] flat_array_view feature request.
by Mostafa 14 Jan '14

14 Jan '14

I think having a flat_array_view adapter in boost would be helpful. Something along the lines of https://github.com/m-w-a/sandbox/blob/master/flat_array_view.cc What do the maintainer(s) of Range and others think? Mostafa

5 7

[block_ptr] & Java
by Phil Bouchard 14 Jan '14

14 Jan '14

Hello everyone, In a quest to speed up my Android applications and knowing Java is written in C++, I decided to discuss with the OS community openjdk.java.net to try to introduce them block_ptr. But the conversation was dead in the water probably due to the lack of developers. So I just have questions: - Does anybody know if Java uses Boost? - block_ptr hasn't been reviewed yet but memory management is an important subject. Are there unanswered questions about it? Sincerely, -Phil Experiment proposal to refute Special Relativity for the interested: http://finitetheory.com/files/experiment.pdf

11 39

[predef] [rfc] Mutually exclusive definitions?
by Rene Rivera 13 Jan '14

13 Jan '14

After going back and re-reading various commentaries for the review of Boost.Predef and some after the review I'm questioning a design choice of Boost.Predef. Currently Boost.Predef will define multiple symbols when, for example, a compiler "emulates" another compiler. The current common occurrence of this is the GCC compiler which many other compilers emulate by defining the GCC version macros. This is no longer the case for the OS definitions though. The OS definitions are mutually exclusive. And hence in order to make for a more consistent behavior I am considering changing the library to make not just OS defs mutually exclusive. But also making compiler, library, and architecture mutually exclusive. And I'm asking for some general feedback as to what the most useful approach, from using Boost.Predef, is likely to be. In particular I'm considering the following choices: 1. Simple mutual exclusion of BOOST_ARCH_*, BOOST_COMP_*, BOOST_LIB_C_*, BOOST_LIB_STD_*, and of course BOOST_OS_* definitions. 2. Mutual exclusion of the base/real definitions with the addition of *_EMULATED definitions when multiple defs detected. For example for GCC we would have BOOST_COMP_GCC_EMULATED indicated the version of the GCC being emulated. 3. No mutual exclusion of base definitions but with the addition of a "flag" definition when multiple defs are detected. For example with GCC it would have the usual BOOST_COMP_GCC but also have a "#define BOOST_COMP_GCC_IS_EMULATED". 4. Do nothing and live with multiple definitions and the current discrepancy in behavior for BOOST_OS definitions. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[TypeTraits] propose new callable-type call traits
by Hui Li 13 Jan '14

13 Jan '14

I've implemented a few traits classes (code attached below) that, for a given callable-type T, and a set of Args..., detects whether the function call T::operator()(Args...) would be (1) valid, (2) ambiguous, or (3) none is viable. where T is allowed to have arbitrary overloaded operator()'s. This could be useful for programmers who want to (1) make the function call only when it's valid, (2) generate customized error/warning messages when it's ambiguous, or handle/redirect it without getting an ambiguous compiler error, and (3) redirect non-viable calls to some default behavior, which can be different than how it's handled when the call is ambiguous. If people are interested, I suppose this could be a useful addition to TypeTraits. I would appreciate any feedback! For clarity, the implementation and demonstration attached below is written in c++11. It can be easily ported to c++98/03 compilers by using TypeTratis to replace the std type traits, BOOST_TYPEOF_KEYWORD to replace decltype, and Boost.Preprocessor to generate code for arbitrary arity. - Hui Li #include <utility> #include <type_traits> template < typename T > struct is_callable; template < typename Signature > struct has_valid_call; template < typename Signature > struct has_ambiguous_call; template < typename Signature > struct has_no_viable_call; template < typename T > struct is_callable { struct yes {}; struct no {}; struct ambiguate_seed { void operator()(); }; template < typename U, bool=std::is_class<U>::value > struct ambiguate : U, ambiguate_seed {}; template < typename U > struct ambiguate<U,false> : ambiguate_seed {}; template < typename U, typename = decltype(&U::operator()) > static constexpr no test(int); template < typename > static constexpr yes test(...); static bool constexpr value = std::is_same<decltype(test< ambiguate<T> >(0)),yes>::value ; typedef std::integral_constant<bool,value> type; }; template < typename T, typename... Args > struct has_valid_call< T(Args...) > { struct yes {}; struct no {}; template < typename U, bool = is_callable<U>::value > struct impl { template < typename V, typename = typename std::result_of<V(Args...)>::type > struct test_result { using type = yes; }; template < typename V > static constexpr typename test_result<V>::type test(int); template < typename > static constexpr no test(...); static constexpr bool value = std::is_same<decltype(test<U>(0)),yes>::value; using type = std::integral_constant<bool, value>; }; template < typename U > struct impl<U,false> : std::false_type {}; static constexpr bool value = impl<T>::value; using type = std::integral_constant<bool, value>; }; template < typename T, typename... Args > struct has_ambiguous_call< T(Args...) > { struct ambiguate_seed { void operator()(...); }; template < class U, bool = is_callable<U>::value > struct ambiguate : U, ambiguate_seed { using ambiguate_seed::operator(); using U::operator(); }; template < class U > struct ambiguate<U,false> : ambiguate_seed {}; static constexpr bool value = not has_valid_call< ambiguate<T>(Args...) >::value; using type = std::integral_constant<bool, value>; }; template < typename T, typename... Args > struct has_no_viable_call< T(Args...) > : std::integral_constant<bool, not (has_valid_call<T(Args...)>::value or has_ambiguous_call<T(Args...)>::value)> {}; #include <string> #include <vector> struct test { void operator()(int); void operator()(double); void operator()(int,double); template < typename T > typename std::enable_if< not std::is_integral<T>::value >::type operator()(const T&, int=0){} template < typename T > typename std::enable_if< std::is_integral<T>::value >::type operator()(const std::vector<T>&, T*){} template < typename T > int operator()(const std::string&, int){} }; int main(int argc, const char * argv[]) { static_assert( is_callable<test>::value , ""); static_assert( not is_callable<int>::value , ""); static_assert( has_valid_call<test(char const*,long)>::value , ""); static_assert( has_valid_call<test(std::string&,long)>::value , ""); static_assert( has_valid_call<test(std::vector<int>, int*)>::value , ""); static_assert( has_no_viable_call<test(std::vector<double>, double*)>::value , ""); static_assert( has_valid_call<test(int)>::value , ""); static_assert( has_valid_call<test(int,double)>::value , ""); static_assert( not has_valid_call<test(int,double,int)>::value , ""); static_assert( not has_ambiguous_call<test(double)>::value , ""); static_assert( has_ambiguous_call<test(unsigned)>::value , ""); static_assert( not has_no_viable_call<test(unsigned)>::value , ""); static_assert( not has_no_viable_call<test(int)>::value , ""); static_assert( has_no_viable_call<test(void)>::value , ""); return 0; }

5 16

[Macro]Test Case grouping using Traits
by Hemanth Choudary M V (RBEI/ETA1) 13 Jan '14

13 Jan '14

Hello, I have observed that in native unit test framework(c++), there is an option to group test cases using attributes which are reflected as traits in the Test Explorer window in MS VS2012. Following is a an example of the same: BEGIN_TEST_METHOD_ATTRIBUTE(TestMethod3) TEST_OWNER(L"SuperMan") TEST_PRIORITY(2) TEST_METHOD_ATTRIBUTE(L"Category",L"Slow") END_TEST_METHOD_ATTRIBUTE() TEST_METHOD(TestMethod3) { Assert::AreEqual(2,6); } How can this be achieved via Boost Unit Test Library? Are there macros to achieve the same? Mit freundlichen Grüßen / Best Regards, Hemanth Choudary MV RBEI/ETA1

2 1

[Test] Problems with debug::break_memory_alloc
by Fredrik Orderud 13 Jan '14

13 Jan '14

I have a problem with the memory-leak detection logic in boost.test. What happens when unit_test::framework::init starts up on Windows is that memory-leak detection is first explicitly activated. Secondly, debug::break_memory_alloc is called with a value (default is 1). Activation of leak detection is great, but to always override the allocation number to break on is not necessary a good idea if the user has already set a value from a debugger. In my case I am investigating a leak from a static member allocated prior to main and/or boost.test being invoked. In that case, I need to break the program early to be able to set the allocation number to break on. This works well by itself, but it's _very_ confusing when boost.test afterwards replaces my allocation number with a default value. Could it be possible to modify boost.test, so that it only modifies the allocation number to break on if the user has explicitly requested to break on a given allocation? Thanks in advance, Fredrik Orderud

2 4

[test] broken (fails to compile) with boost.timer since 1.48
by Jamie Allsop 13 Jan '14

13 Jan '14

Boost.Test fails to compile since 1.48 when Boost.Timer is included. I find that often I want to use timers when testing. I reported this back in 2012 along with a comprehensive patch that fixes the issue. On the eve of 1.55 I see the patch has still not been applied, despite an original agreement to do so. Unfortunately I don't have commit privileges so I am unable to do this myself. The original discussion from here: http://lists.boost.org/Archives/boost/2012/09/196811.php went as follows: > On 25/09/12 18:14, Gennadiy Rozental wrote: >> Jamie Allsop<ja11sop<at> yahoo.co.uk> writes: >> >>> >>> These are patches we've been using for some time locally, the recent >>> discussions highlighted the importance of pushing patches like these to >>> a wider audience. >>> >>> In summary the key changes are: >>> >>> * https://svn.boost.org/trac/boost/ticket/7410 >>> * https://svn.boost.org/trac/boost/ticket/7397 >> >> These are fine. I'll try to check it in on a weekend > > Excellent thanks! Yet https://svn.boost.org/trac/boost/ticket/7397 was never applied. With changes to Boost.Test since then it is likely that the patch needs modified to be applied but that should not be too hard. Apart from that I'd like to see the suite of 4 patches applied as a whole. So far only https://svn.boost.org/trac/boost/ticket/7410 has been applied but the patches address severe use-case short-comings in Boost.Test that make it viable for broader testing use. I've summaried them below. * https://svn.boost.org/trac/boost/ticket/7397 * https://svn.boost.org/trac/boost/ticket/7410 (applied) * https://svn.boost.org/trac/boost/ticket/7417 (small) * https://svn.boost.org/trac/boost/ticket/7419 (small) Original discussion that didn't really get very far was in these threads: * http://lists.boost.org/Archives/boost/2012/09/196811.php * http://lists.boost.org/Archives/boost/2012/09/196828.php For those who are interested I've pasted my original motivations from the year old thread below as a reminder. Basically the patches allow Boost.Test to: * compile with Boost.Timer (so not broken) * output test progress on the fly in a format other tools could parse * allows Boost.Test to be used for live test diagnostics in running systems in a 'test' mode Jamie * https://svn.boost.org/trac/boost/ticket/7410 (applied) * all test cases/suites have file and line information captured so that external tools can use the Boost.Log output to create links into the source tree, answering questions like, "What is this test case?". It is possible to simply follow the link and see. * https://svn.boost.org/trac/boost/ticket/7417 * update the Boost.Test log output to include summary status information when a test case or suite is completed. This includes the test status, assertions passed and total assertions. This allows live test status to be viewed and nicer tools to be built around this. For example each test can be shown starting, in progress and then complete with the resulting status in detail. I should note that Boost.Test reports currently output this additional test status but this is done only on *completion of all tests* and so *cannot* be used to show live progress. * this additional test status as part of the log can be easily captured using regular expressions if HRF is used and many IDEs will allow colourisation, autolinking and so on using similar approaches. * https://svn.boost.org/trac/boost/ticket/7397 * update Boost.Test to use the new Boost.Timer classes introduced in Boost 1.48. This can be suppressed through the use of a macro should the old timers be preferred. The new Boost.Timer provides much better timing information than the old Boost.Timer library. You should refer to the library itself for an explanation of why the previous timer library was deprecated: http://www.boost.org/doc/libs/1_51_0/libs/timer/doc/index.html * https://svn.boost.org/trac/boost/ticket/7419 Essentially the patch does two things: * It allows boost::unit_test_framework::init() to be called more than once. The result is to reset the test status and master test suite so that new tests can be added and new reports generated through multiple calls. The CLA parsing is also reset. Recent changes to this code may make my call to clear() redundant. I'll let Gennadiy be the judge of that. * This first change then allows the framework setup and teardown to be encapsulated in a helper class (not provided in the patch but one could be). In our systems we use a helper class that exposes a simple API that allows the user to implement a method where test units can be added directly to the master test suite - see the ticket for an example. As I said the patch focuses solely on enabling the possibility of writing such a class, not the class itself. * It provides scoped Boost.Test arguments for the commandline when BOOST_TEST_USE_QUALIFIED_COMMANDLINE_ARGUMENTS is defined. All command line arguments are then called --boost.test.<argument> for example --boost.test.log_level instead of --log_level. This of course means that all Boost.Test related arguments will not clash with any program arguments. On its own this is a generally useful feature as it allows custom main() functions to pass arguments down to other components during simple unit testing.

2 1

Boost unit test with BOOST_NO_EXCEPTIONS
by driscoll 13 Jan '14

13 Jan '14

I work on a team that uses compiles with exception support disabled. (That... is not my decision, and no value judgments on that, please. :-)) I'd kind of like to use the unit test library. However, at a surface level it has lots of uses of raw try/catch/throw instead of BOOST_TRY/BOOST_CATCH/BOOST_THROW. At a deeper level, I suspect what's doing is throwing an exception on an EXPECT or ASSERT failure -- and thus that disabling exceptions will basically mean that a test failure will cause an immediate abort in the program. (I guess I can hack around that in an ugly but somewhat-reasonable way.) How hopeless is using the library with BOOST_NO_EXCEPTIONS? Evan

3 2

(no subject)
by Gly Marvellou 13 Jan '14

13 Jan '14

Hi, I'm a CS major and new to this list. I want to contribute to Boost C++ libraries under GSOC 14. Can someone guide me through? Gly

1 0

Data-Structures, Ideas. GSoC 2014
by Ankit Vadehra 12 Jan '14

12 Jan '14

Hi, I'm Ankit Vadehra, and i was contacting to ask whether Boost is considering participation in GSoC 2014, and if it is, then are there some new ideas of some priority Data Structures Classes that are to be introduced in Boost ?? For Example, previously have worked on Trie Data Structure as well as Boom Filters and so on, but none of these advanced data-structures were merged in the main library, anyways.. Anyways, are there any new ideas?? GSoC, ain't that far away now, and Idea Page is till not up.. ?? Is someone working on it, by any chance ? Thanks.! -- Ankit.Vadehra "The Code Is free, But its Priceless" "Exactly, which way is Forward ?"

1 0