February 2015 - Boost - lists.preview.boost.org

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

[multiprecision] uses boost::math::gcd without including the header
by Peter Dimov 04 Jan '16

04 Jan '16

include/boost/multiprecision/cpp_int/misc.hpp uses boost::math::gcd (and lcm), but does not include common_factor_rt.hpp.

2 2

[variant] Opinion on boost::safe_get<> and default boost::get<> behavior
by Antony Polukhin 18 Dec '15

18 Dec '15

Hi all, I'm in doubt and would like to hear opinions on the following issue. boost::get for boost::variant was not making any compile time checks, resulting in runtime errors where a compile time error must be: boost::variant<int, string> v(100); boost::get<bool>(&v); // returns NULL instead of compile time error boost::get<bool>(v); // throws exception on runtime instead of compile time error Now we have an implementation of compile time checked get in a separate branch at git: boost::variant<int, string> v(100); boost::safe_get<bool>(&v); // compile time error boost::safe_get<bool>(v); // compile time error boost::unsafe_get<bool>(&v); // returns NULL instead of compile time error boost::unsafe_get<bool>(v); // throws exception on runtime instead of compile time error I'm in doubt, what the default behavior of boost::get must be: * safe_get behavior is much closer to Standard Library behavior (just like std::get for tuples) and allows to avoid errors in user code * unsafe_get behavior is same as behavior of old boost::get and won't break user's code if boost::get is used in some generic contexs What's your opinion? -- Best regards, Antony Polukhin

10 13

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

Test Runner Update to vc14.0 - CTP 6
by Tom Kent 23 Jul '15

23 Jul '15

Just a heads up, I have just updated the test runner teeks99-08f-win2012R2-64on64 from vc14.0 - CTP 4 to vc14.0 - CTP 6. The change should show up in the next run of that runner in a few hours. I think some people were waiting to see if MS was fixing some things, so I thought I'd send a message letting people know these results would be available. Tom

7 22

[coroutine2] add to testing
by Oliver Kowalke 21 Jun '15

21 Jun '15

Hi, I'm uncertain if boost.coroutine2 (C++11-only) will be part to the 1.58 release - a git-submodule exists but not at the list for the regression tests (I've opened a pull-request to boostorg/boost). Could you tell me the status of boost.coroutine2?! thx, Oliver

2 3

[ boost ] [ Trie ]
by Cosmin Boaca 06 May '15

06 May '15

Hello, I am interested in working at the Boost.Trie project which was started during GSoC 2013 and I am searching for someone who can give me some advice about what should I change / add to the current implementation, because I'm not too experienced in developing library code. However, I do not want do this during GSoC because I won't be available during the summer. I want to contribute during my spare time. If anyone thinks that can help me with this, please reply to this email. Thank you, Cosmin

8 90

Latest dependency report
by Peter Dimov 25 Apr '15

25 Apr '15

... generated from the develop branch: http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-overview.html http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-levels.html http://www.pdimov.com/tmp/report-develop-c3bb6eb/module-weights.html

2 2

htmlspecialchars and urlencode?
by Olaf van der Spek 14 Apr '15

14 Apr '15

Hi, Does Boost have functions like htmlspecialchars and urlencode (from PHP)? If not, I think they'd make a nice addition to the string algorithm lib. -- Olaf

4 6

Conflicts when building libraries at root
by Peter Dimov 31 Mar '15

31 Mar '15

On Windows, at least, when I do ./b2 toolset=msvc-8.0 at Boost root, I get error: Name clash for '<pstage\lib>libboost_system-vc80-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <warnings>all error: - <address-model>32 <architecture>x86 <warnings>on When I add --without-context --without-coroutine, I now get error: Name clash for '<pstage\lib>libboost_system-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>off error: - <asynch-exceptions>on So I add --without-test. error: Name clash for '<pstage\lib>libboost_timer-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>on <library>object(file-target)@10959 error: - <asynch-exceptions>off <library>object(file-target)@9953 Now where did _that_ come from. :-) Ah. --without-endian. Builds now. This is perhaps old news for some, but it looks like it doesn't play well with our simple build instructions. Or maybe it doesn't occur on the master branch, so we don't care? I haven't checked yet. It's also perhaps an indication of a deeper problem. I can use b2 --with-test and have 'test' built; it builds its dependencies (system, chrono and timer) with <asynch-exceptions>on in bin.v2, and if I use it from within Boost.Build, it will link to them. But if I stage (or install) Boost.Test, and then stage or install Boost.System separately, Boost.System will be built with <asynch-exceptions>off. So the library user who just has headers and binaries will link those, potentially creating a conflict, which may in this case be benign. Or not.

12 55

sun toolset buggy and outdated?
by John Maddock 28 Mar '15

28 Mar '15

I'm trying to test the new Oracle-solaris compiler but I'm running into Boost.Build issues. First off what looks like a bug, if I build with with b2 stdlib=native Then I *still* get stlport You can easily reproduce this on another platform with: cd libs/config/test ../../../b2 config_info toolset=sun stdlib=native -n -d2 which yields: sun.compile.c++ ..\..\..\bin.v2\libs\config\test\config_info.test\sun\debug\stdlib-sun-stlport\config_info.obj "CC" +d -library=stlport4 -g -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -c -o "..\..\..\bin.v2\libs\config\test\config_info.test\sun\debug\stdlib-sun-stlport\config_info.obj" "config_info.cpp" Now for the outdated part: the oracle compiler (12.4) now supports three std lib options: 1) The default - I can't make this work in C++03 mode, but it's the only option that does work in C++11 mode (where it appears to be a recent GNU libstdc++ version). 2) STLPort - only works in C++03 mode. 3) Apache - only works in C++03 mode. So ideally we would probably have: stdlib=stlport, sets -library=stlport4 for both compile and link. stdlib=apache, sets -library=stdcxx4 for both compile and link stdlib=native, sets -std=c++11 for both compile and link. And yes I realise we're mixing up two different features here, but as they can't be mixed and matched anyway it at least gets things working. I guess the toolset should be renamed either "oracle" or "solaris" as well? If anyone has any ideas how to patch the toolset, I have a working virtual machine to test on (or you can do as I did and download a pre-build VirtualBox machine). Thanks in advance, John.

5 13

[SORT] Parallel Algorithms
by Francisco José Tapia 26 Mar '15

26 Mar '15

Sorry by the delay, As promised, the sorting parallel algorithms On my computer (Quad Core) the GCC std::sort and stable_sort are slight faster than my version of intro_sort and merge_sort (stable sort is a synonym of merge_sort). In other computer with an Intel I3, my algorithms are slight faster than in the GCC version. Trying to optimize the parallel implementation. I modified the parallel version for to use the std::sort and std::stable_sort. The parallel_sort version response good, but the parallel_stable_sort increase the time around a 60% compared with the version with countertree::parallel_merge_sort . After many test, I discover the cause of the problem. The demonstration is in the test_stress_sort_01.cpp. In this program we have a big vector of 100 000 000 elements uint64_t. The program make parts of the same size for each HW core. On my computer 4 parts and 4 cores. The program execute the part sequentially checking the time, and after do the same but in parallel, each thread sort a part, and check the time. This is done with the std::stable sort and countertree::merge_sort. The data input is the same for all. The next lines are the result show max. OpenMP threads: 4 (4 processors) Sort of 100000000 elements in a vector --------------------- Random elements, few repeated ( rand() )----------------------- Stable Sort Part 0 secs :2.77955 Part 1 secs :2.75015 Part 2 secs :2.76068 Part 3 secs :2.76284 Parallel Sort secs :8.49796 Countertree stable sort Part 0 secs :2.72802 Part 1 secs :2.71614 Part 2 secs :2.72074 Part 3 secs :2.722 Parallel Sort secs :4.80692 Surprisingly the parallel sort with countertree::stable_sort is much more faster than the sort with std::stable_sort in the GCC 4.8 and 4.9 compiler. This is the secret of the speed of the countertree::parallel_merge_sort. This is very important, because when the size of the elements is small, the GCC and the countertree algorithms have similar performance. But when the size of the elements grow, the std::stable sort is slower than the countertree::merge_sort. This difference is increased in the parallel version. The next lines are part of benchmark_sort_05.cpp *************************************************************** Sort of N = 6250000 elements of size 128 ***************************************************************** Random elements, few repeated ( rand() )----------------------- STL std::sort :2.9188 secs countertree::intro_sort :2.87864 secs parallel::sort :2.46113 secs tbb::parallel_sort :1.86458 secs countertree::parallel_sort:1.89263 secs std::stable_sort :8.77963 secs countertree::merge_sort :5.70694 secs parallel::stable_sort :8.03946 secs countertree::parallel_merge_sort :4.90815 secs I have in mind a new version of the stable sort in order to improve the speed, reducing the number of internal copy of elements. I hope to have time in Christmas, but I can't guarantee. If the results are the expected I will send you You have too, a version of indirect_sort, which sort pointers to the elements, and at end sort the elements according the pointers. You can replace any sort algorithm by their indirect version, obtaining the same results, with the only difference of the time needed. You have a benchmark_indirect_sort.cpp where see the comparison of the time needed of several sort methods and their indirect version with elements of different size. This code is a preliminary version, done for my countertree library. If you consider useful, I will change the name space and document the code, the algorithms and the ideas obtained from the benchmarks. Please feel free for ask me any question or for to modify or change anything. The goal is to provide good sort methods to the users. In the zip file you have the code and a file with a description of each code. Yours

5 20

[rational] has no maintainers
by Peter Dimov 23 Mar '15

23 Mar '15

Currently, nobody has write access to Boost.Rational, and I see a number of open pull requests (mostly by John Maddock) lingering. John, would you like write access to it so that you can apply your suggested changes?

5 6

transforming ex. boost lib into C++11-only lib?
by Oliver Kowalke 23 Mar '15

23 Mar '15

Hello, is it permitted to transform an existing boost library into a C++11-only library? best, Oliver

15 19

To split, or not to split, or something else? RE: type_traits rewrite, modularization, dependencies, etc.
by Rene Rivera 20 Mar '15

20 Mar '15

I keep reading emails about the effort to reduce dependencies, and to split libraries into core/simple + whole/big.. And I keep thinking it's making things more complex than they need to be. I can see the need to compartmentalize the parts of a library that have minimal to little dependencies. So here's a suggestions for structure of managing this. I see options: 1. In each library allow for a "core" set of headers that are still in a core subdir. But that we can tell is a subset of the library that has the minimal dependencies. For example we would have: * libs/<lib>/include/boost/<lib>/core/.. * libs/<lib>/include/boost/<lib>/<the-rest>.. This of course assumes that it's headers only that would be core. Second option is to have each library have to explicit sublibs/parts. "core" and "full". Structure would be: * libs/<lib>/core/(build, doc, include, meta, test) * libs/<lib>/full/(build, doc, include, meta, test) Note, both core and full would be in the same git repo to make life easier for library authors and users that visit a library git repo on github. As it's only one place for everything for that one library. As a user, release manager, testing manager, and library author this would be easy to understand and manage than the current "some random set of libraries have core or not and in different places". -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

6 11

[test] boost.test owner unresponsive to persistent problems for multiple years
by legalize+jeeves＠mail.xmission.com 18 Mar '15

18 Mar '15

[Please do not mail me a copy of your followup] See <https://svn.boost.org/trac/boost/ticket/10888> and <http://stackoverflow.com/questions/5209625/boost-test-error-messages-are-no…> Both contain a fix for this. On stack overflow the proposed fix is literally a single line change. This has been a problem for about 5 years and these simple fixes don't make it into the library. I'm sorry, but IMO this just isn't acceptable behavior for an owner of a library. Four years ago the maintainer made a comment on stack overflow thread to file a ticket on trac and then simply dropped the issue there as far as I can tell. That isn't proactive behavior, particularly when the stack overflow thread contains the fix. I know what you're going to say "the trac ticket was just filed a few days ago", but that's simply me pushing hard on something that should have been fixed around 2010. The problem has been known FOR FIVE YEARS and is EASY TO FIX. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

24 77

[mpl] multiset
by Bruno Dutra 16 Mar '15

16 Mar '15

Hi Folks, Anyone knows what's up with this so called "multiset" I just found fiddling with the source code? The poor thing seems to have been left unfinished :( Any reasons anyone would not just go ahead and try bringing it to life? I would definitely be up to take the first step, I just don't know whether not I should carry on with it, I mean, isn't the whole purpose of all this is encouraging people like myself to take the step ahead and just do it? Anyways, MPL seems to have seen better days of activity back in the day, there's lots of opportunities for improvement still and I for one would be glad to help developing some fancier features. I'd be glad to hear what you guys have to say. Best regards, *Bruno C. O. Dutra*

23 93

Re: [boost] GSOC 2015 : Project on Concurrent Hash Tables
by Amarnath V A 14 Mar '15

14 Mar '15

Thanks for the prompt reply Niall. I have got a few more questions. 1. I could not make out the use of _oldbuckets in the code. What purpose does it serve? 2. I see a swap() function which is not used anywhere in the codebase. Is it dead code? 3. And I have a generic question regarding std::atomic. I was trying to code the move constructor and finally ended up failing miserably to move the reference of _bucket. I could not figure out how to do it. Could you point me to some documentation which would help me to achieve the same. To give a fair idea about my last question, let me elaborate what I was trying to do. I have got the reference of _buckets and have assigned it to new variable using store and load methods of atomic. But, I am not confident if that is the right way to go about. And secondly, I see that I am not able to reset the reference of original. Thanks, Amarnath

3 26

Re: [boost] [Boost-maint] [context, config] Always setting address-model and architecture (Was: Conflicts when building libraries at root)
by Vladimir Prus 11 Mar '15

11 Mar '15

On 02/18/2015 05:55 PM, Jürgen Hunold wrote: > Hi Volodya, > > Am Mittwoch, 18. Februar 2015, 14:28:48 schrieb Vladimir Prus: >> On 01/05/2015 10:37 PM, Jürgen Hunold wrote: >>> >>> Unfortunately, we still have Boost.Context open. >> >> Okay, so the problem we're facing is that building master results in: >> >> error: Tried to build the target twice, with property sets having >> error: these incompatible properties: >> error: >> error: - none >> error: - <address-model>32 <architecture>x86 >> >> What happens is this: >> >> - Context library is built >> - It detects default address model and architecture of the current >> toolchain, and adds those to requirements >> - Since there's a global dependency on 'headers' target, this pretty much >> immediately rebuilds everything with new address-model and architecture >> properties. > > Not correct: Boost.Context needs Boost.System so it requires a build with > those properties. As they have currently have no defaults, the explicit values > differ from the implizit default (none) for both. Well, it my brief check, it was the headers->system path that first requested system with address-model=32. Anyway, it does not matter for the rest of this discussion. >> - We get property set clash > > Correct. > >> One way to solve this is to restructure Boost.Context setup so that added >> properties do not escape. It's doable, but probably will be fragile. > > No doubt. > >> Another way is to take libs/context/config, move it to libs/config, and make >> sure these properties are applied globally. That seems preferable. John, >> any objections? > > I thought the correct way would be to move the architecture detection upwards? That's roughly what I propose, too - but there are few further tweaks and options. > We would need something along those lines (from context/bulld/Jamfile.v2) > > alias select_asm_context_sources > : asm_context_sources > : [ architecture.architecture ] > [ architecture.address-model ] > ; > > in boostcpp.jam in order to detect the architecture everywhere. It would then > be helpfull to have sensible default values in order to shorten the generated > paths for those defaults. Right, so steps would be: 1. Move actual tests into config (we do need to have a few cpp files) 2. Move architecture.jam into either Boost.Build or boostcpp.jam 3. Make sure we don't generate extra path elements for default address model 4. Introduce a way to do these tests without requiring a bunch of .cpp files - sure Boost.Build can generate them on the fly. 5. Make these checks be automatic for all projects. It seems that 1-2 should solve the immediate problem, and 1-3 should be pretty good, although going all the way to 5 would be cool. > Another solution would be to generate a "header-only" variant of Boost.System > and use this nearly everywhere. This would solve *lots* of dependency > problems... Not sure I have an opinion on that. -- Vladimir Prus CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software/

7 13

[dynamic_bitset] Maintainer available?
by Riccardo Marcangelo 07 Mar '15

07 Mar '15

Hi Boost developers, Does anybody know if the maintainer of dynamic_bitset is available? I made some contributions to dynamic_bitset on GitHub last year but there doesn't appear to have been any activity in the repository for many months. My pop_back() commit was accepted into the 'develop' branch over 5 months ago and, despite passing tests, has yet to be merged to 'master'. I also implemented capacity(), reserve(), and shrink_to_fit() which have been sitting in a pull request waiting to go into 'develop' since November. It would be nice to get these into 1.58.0 if possible. Kind regards, Riccardo -- View this message in context: http://boost.2283326.n4.nabble.com/dynamic-bitset-Maintainer-available-tp46… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[build] adding a rquirement for Cygwin only?
by Peter Dimov 05 Mar '15

05 Mar '15

Is it possible to add, for example, <threadapi>pthread to a project's requirements, but only for Cygwin? This works: <toolset>gcc,<target-os>windows:<threadapi>pthread but it also applies to MinGW. This only applies to MinGW: <toolset-gcc:flavor>mingw:<threadapi>pthread but Cygwin has no <flavor>. This: <toolset>gcc,<target-os>windows:<threadapi>pthread <toolset-gcc:flavor>mingw:-<threadapi>pthread doesn't work. There are references to <target-os>cygwin in gcc.jam, but <target-os> is actually 'windows'.

3 6

[build] b2 headers broken?
by Eric Niebler 02 Mar '15

02 Mar '15

I just updated to the latest develop. I ran bootstrap, then nuked my boost directory and reran b2 headers. Worked fine. Then I changed directory to libs/proto/test and ran ../../../b2 mem_ptr to run a test. Here's what I get: f:\modular-boost\libs\proto\test>..\..\..\b2 mem_ptr Performing configuration checks - symlinks supported : no - junctions supported : yes - hardlinks supported : yes ...patience... ...patience... ...found 4951 targets... ...updating 441 targets... common.mkdir ..\..\..\bin.v2\libs common.mkdir ..\..\..\bin.v2\libs\proto common.mkdir ..\..\..\bin.v2\libs\proto\test common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0 common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug\link-static common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug\link-static\threading-multi link.rm ..\..\..\boost\mpl common.mkdir ..\..\..\boost\mpl link.hardlink ..\..\..\boost\mpl\print.hpp Hardlink created for ..\..\..\boost\mpl\print.hpp <<===>> ..\..\mpl\include\boost\mpl\print.hpp <snip> link.rm ..\..\..\boost\numeric\conversion link.hardlink ..\..\..\boost\numeric\conversion\conversion_traits.hpp The system cannot find the path specified. if exist "..\..\..\boost\numeric\conversion\conversion_traits.hpp" del "..\..\..\boost\numeric\conversion\conversion _traits.hpp" mklink /H "..\..\..\boost\numeric\conversion\conversion_traits.hpp" "..\..\numeric\conversion\include\boost\numeric\ conversion\conversion_traits.hpp" ...failed link.hardlink ..\..\..\boost\numeric\conversion\conversion_traits.hpp... link.hardlink ..\..\..\boost\numeric\conversion\int_float_mixture_enum.hpp The system cannot find the path specified. For some reason, b2 thinks it needs to rerun b2 headers, but it does a crap job of it and dies. What's going on? Eric

4 6

Re: [boost] [Boost-interest] Biicode dependendy manager with Boost support
by Vicente J. Botet Escriba 27 Feb '15

27 Feb '15

Le 20/02/15 20:54, JOAQUIN M. LOPEZ MUÑOZ a écrit : > Hi, > > The folks at biicode (biicode.com) a C/C++ dependency manager, have just > announced support for Boost: > > http://blog.biicode.com/dependency-management-boost-libraries/#more-2086 > > Biicode allows for easy multiplatform component tracking and builiding > thanks to their file-based dependency detection and CMake autogeneration > magic. Now, these capabilities can be used to make it easier to work with > Boost libraries. > Thanks Joaquin for the announce. I was wondering if we couldn't use it as a starting point of our modularization activity. Some questions: * Is the file-based dependency manager what Boost is looking for its own module dependencies detection? * Could an author state explicitly its dependencies on other libraries (versions)? * It Biicode open source? * How its CMake autogeneration and bjam interact? Best, Vicente

4 4

VMD library accepted
by Steven Watanabe 27 Feb '15

27 Feb '15

AMDG The VMD library submitted by Edward Diener is ACCEPTED into Boost. I apologize for the long delay for this announcement. Thanks to everyone who participated in the formal review * Nial Douglass * Bjorn Reese * Rodrigo Madera * Zhou Zhenghui * Matt Calabrese * Paul Mensonides Reviews for the library were generally positive. The library was considered to be a useful set of tools for macro programmers. Paul expressed concern about the way the the library handles v-sequences and v-identifiers. After some discussion, Edward has agreed that the interface could be significantly improved. Work Items: * Add examples and improved motivation in the documentation * Update the v-identifier/v-sequence interface based on Paul's comments * Fix inaccurate statements about Boost.Preprocessor per Paul In Christ, Steven Watanabe

1 0

[1.58] Any plans to merge the super-project to master?
by John Maddock 26 Feb '15

26 Feb '15

Is the Boost super-project going to be merged to master, Jamroot in particular has several important unmerged changed. Thanks, John.

1 0