- Boost - lists.preview.boost.org

[serialization]cannot build libboost_serialization.so.1.60.0 with Oracle Solaris Studio
by Aparna Kumta 28 Oct '15

28 Oct '15

I see the following error when compiling Boost 1.60 in develop branch with Oracle Solaris Studio development compiler with -library=stlport4. "CC" -compat=5 -library=stlport4 -temp=/tmp/bn -xO4 -mt -erroff=%none -m32 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_regression_develop/boost_sparc-S2_stlport4/results/boost/bin.v2/libs/serialization/build/sun-next_stlport4/release/link-static/threading-multi/basic_text_iprimitive.o" "../libs/serialization/src/basic_text_iprimitive.cpp" "../boost/archive/basic_streambuf_locale_saver.hpp", line 75: Error: sync is not a member of std::ios . "../boost/archive/impl/basic_text_iprimitive.ipp", line 112: Where: While instantiating "boost::archive::basic_ios_locale_saver<char, std::char_traits<char>>::~basic_ios_locale_saver()". "../boost/archive/impl/basic_text_iprimitive.ipp", line 112: Where: Instantiated from boost::archive::basic_text_iprimitive<std::istream>::basic_text_iprimitive(std::istream &, bool). "../libs/serialization/src/basic_text_iprimitive.cpp", line 25: Where: Instantiated from non-template code. 1 Error(s) detected. This seems to prevent building libboost_serialization.so.1.60.0, and a recent regression after changes to the serialization library. Thanks, Aparna

3 4

[type_traits][multi_index][msvc-7.1] problems with is_const in VC 7.1
by Joaquin M López Muñoz 27 Oct '15

27 Oct '15

> Hi, Boost.MultiIndex is failing at master for VC 7.1: http://tinyurl.com/oxflkj6 .\boost\multi_index\identity.hpp(75) : error C2535: 'Type &boost::multi_index::detail::const_identity_base<Type>::operator() (const boost::reference_wrapper<Type> &) const' : member function already defined or declared the problem seemingly being with boost::is_const. The offending code looks like template<typename Type> struct const_identity_base { // produces the error above if Type is not const }; template<typename Type> struct non_const_identity_base { ... }; template<class Type> struct identity: mpl::if_c< is_const<Type>::value, detail::const_identity_base<Type>, detail::non_const_identity_base<Type> >::type { }; Boost.TypeTraits recently changed its is_const implementation to the very simple template <class T> struct is_const : public false_type {}; template <class T> struct is_const<T const> : public true_type{}; template <class T, size_t N> struct is_const<T const[N]> : public true_type{}; template <class T> struct is_const<T const[]> : public true_type{}; which relies on template partial specialization (supposedly supported by VC 7.1). Yet, seems like const_identity_base is wrongly selected for a non-const Type. Any clues about what might be going on? Thank you, Joaquín M López Muñoz Telefónica

5 15

[tools] updating sun.jam
by Aparna Kumta 27 Oct '15

27 Oct '15

I am not familiar with the syntax to update sun.jam file. In tools/build/src/tools/sun.jam, lines 153-156 contain 153: actions link.dll bind LIBRARIES 154: { 155: "$(CONFIG_COMMAND)" $(OPTIONS) -L"$(LINKPATH)" -R"$(RPATH)" -o "$(<)" -h$(<[1]:D=) -G "$(>)" "$(LIBRARIES)" -Bdynamic -l$(FINDLIBS-SA) -Bstatic -l$(FINDLIBS-ST) -B$(LINK-RUNTIME) 156: } Only if compiling with -std=c+11 or -std=c++14, I need to replace '-G' above with '-G -library=stdcpp,CrunG3' Any help on modifying this is appreciated. Thanks, Aparna

1 0

1.60 closes for major changes next Wednesday
by Vladimir Prus 27 Oct '15

27 Oct '15

1.60 is now closed for new libraries and breaking changes - please don't merge such changes for master. We'll be closed for major changes next Wednesday, Oct 28, at the end of the day. Thanks, -- Vladimir Prus http://vladimirprus.com

3 3

[vmd] Added to new release
by Edward Diener 26 Oct '15

26 Oct '15

I would like to make sure the VMD library is added to the upcoming Boost 1.60 release. Is there anything further I have to do to affect that ?

1 0

[Hana] Postponing release to 1.61.0
by Louis Dionne 24 Oct '15

24 Oct '15

Hi, Some of you might know that I have been pushing hard to deliver Hana with the next Boost release. I have even taken the (soft) engagement to do so at CppCon in last September. However, due to some time constraints, it is now clear that Hana will not be included in Boost 1.60.0, the limit for new libraries being yesterday. I hoped really hard to make it in time for Boost 1.60.0, but the closing of the release branch ~1 month before the release date got me by surprise. All in all, this is not too bad since there are still a couple issues that must be addressed, and I believe that taking more time to address them properly will be beneficial to the community in the long term. Also, while I really wanted to make Hana available to the wider community ASAP, I do not think waiting 3 more months will be very harmful. Given the current level of C++14 support in compilers, only people on Clang >= 3.5 would have been able to use Hana, and I do not think this represents such a huge amount of potential users. As a side note, given my previous announcements, some users might find it strange not to see Hana as part of 1.60.0. Hence, I wonder whether it would be possible to include a short note with a link to this message somewhere in the release notes for 1.60.0? Regards, Louis

3 4

[detail] Compilation broken in develop and some questionable ideas
by Antony Polukhin 24 Oct '15

24 Oct '15

Hi, The commit https://github.com/boostorg/detail/commit/9fcf2ae390c7c21a9b42fd40dd5c0eec1… breaks the compilation of Boost.Filesystem: D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(126): error C2487: 'do_in': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(136): error C2487: 'do_out': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(152): error C2487: 'get_octet_count': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(156): error C2487: 'get_cont_octet_out_count': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(189): error C2487: 'do_length': member of dll interface class may not be declared with dll interface According to MSDN only the whole class or class separate members could be decorated with BOOST_UTF8_DECL, not both ( https://msdn.microsoft.com/en-us/library/t72ahzw1.aspx) Now the questionable part... We could theoreticaly avoid duplication of `utf8_codecvt_facet` code in libraries and even avoid code breakage if we: * move `struct utf8_codecvt_facet` to namespace `boost::detail::utf8_codecvt_facet_namespace` * mark all it's functions as inline, even the virtual ones => `inline` will implicitly mark the stuff in `struct utf8_codecvt_facet` as weak symbols, so that multiple occurences of it will be reduced to one by linker * add the using declaration `BOOST_UTF8_BEGIN_NAMESPACE using boost::detail::utf8_codecvt_facet_namespace::utf8_codecvt_facet; BOOST_UTF8_END_NAMESPACE` => using declaration will help the existing code to find class in `BOOST_UTF8_BEGIN_NAMESPACE` defined namespaces. Questionable part number two... Is it time to move Boost.Detail module into Boost.Core/Boost.Algorithm/Boost.MPL? Main points are: * Boost.Detail is really old and many people who maintained it are inactive. Moving it into rapidly developing modules will improve it's support (maybe even docs will appear! or tests!) * Nobody knows what does `Deatil` mean in that particular case. `detail::` namespace is a namespace that user must not use. However there's some cool stuff in Detail module that must be available to users, so the name Detail is obfuscating here. -- Best regards, Antony Polukhin

5 4

Painting a bikeshed ...
by Marshall Clow 21 Oct '15

21 Oct '15

In Sean Parent's CppCon keynote last week, he went through the process of implementing an algorithm he called "sort_subrange", which takes four iterators describing two ranges, one a subset of the other, and sorts the subrange - as if you had sorted the entire range. (See https://www.youtube.com/watch?v=sWgDk-o-6ZE, starting at about 31:30). I have implemented this in Boost.Algorithm (crediting Sean) - called partition_sort. However, while I was doing this, I thought of a different algorithm; one that gathered all the elements into the subrange as if the entire range was sorted, but didn't actually do the sorting. I've implemented that one, too - but I'm having a bit of trouble coming up with a name. I've used "partition_subrange", but that not that clear. Sean has suggested "elements_in_subrange" and "elements_within_subrange". Here's the declaration: template<typename Iterator, typename Pred> void partition_subrange ( Iterator first, Iterator last, Iterator sub_first, Iterator sub_last, Pred p) /// \brief Gather the elements of the subrange [sub_first, sub_last) that is /// inside the range [first, last) as if you had sorted the entire range. Any suggestions? -- Marshall

11 18

(no subject)
by Kabir Sahni 21 Oct '15

21 Oct '15

Hello! I have recently joined the mailing list and i am willing to contribute.Can anyone guide me

2 1

[metaparse] Transferring the repository to Boostorg
by Abel Sinkovics 21 Oct '15

21 Oct '15

Hi, I'd like to transfer my Metaparse repository (https://github.com/sabel83/metaparse) to Boostorg. Based on another thread on Hana, I assume I need temporary admin rights to boostorg to be able to transfer the repository. Please give me temporary admin rights (I've posted an issue for it as well: https://github.com/boostorg/admin/issues/110) or suggest another method for the repository transfer. Thanks, Abel

2 12

[Locale] New utf-8 codecvt facet in master (replacement of boost/details/utf8_codect_facet)
by Artyom Beilis 21 Oct '15

21 Oct '15

Hello, Following previous discussion regarding utf-8 facet in boost. I merged the changes to master branch. New utf8 codecvt facet that properly handles both UTF-16 and UTF-32 encoding for wchar_t (or char16_t/char32_t) is there. The major goal is to replace existing broken (*) utf8 facet existing today in boost/details/utf8_codecvt_facet.hpp/ipp It is implemented in header only so all you need is to include #include <boost/locale/utf8_facet.hpp> And install it as usual: std::locale new_locale(std::locale(),new boost::locale::utf8_codecvt<wchar_t>()); It *does not require* a separate compilation part like the one in details Note it is implemented in terms of boost::locale::generic_codecvt template<typename CharType,typename CodecvtImpl,int CharSize=sizeof(CharType)> class generic_codecvt; That has non-trivial specialization for CharSize=2 and CharSize=4 for UTF-16 and UTF-32 wchar_t/char16_t/char32_t character handling. boost::locale::generic_codecvt provides an interface for creating a range of facets for various character encodings. For example boost.locale uses it to implement various facets: - utf8 codecvt - single byte character set like ISO-8859-* or Windows-125* - wrap ICU ucnv_* and POSIX iconv APIs to create standard codecvt facet. That is why I decided to keep the implementation withing Boost.Locale library as the place that actually deals with different encoding. ----------- Once boost 1.60 will be released I encourage every library maintainer that incorporates broken boost/details/utf8_codecvt_facet.*pp to replace one with proper one from boost.locale Note: it is HEADER ONLY part and does not require any part of compiled library. Artyom Beilis (*) Current implementation does not handle utf-16 properly and can actually produce invalid utf-8

1 0

[Hana] Transferring repository to boostorg on GitHub
by Louis Dionne 19 Oct '15

19 Oct '15

Hi, I would like to know what is required from me to transfer the Hana repository from my GitHub account to boostorg. I reckon I should be added as a member of the boostorg "organization" on GitHub? Regards, Louis

2 14

Re: [boost] [interprocess] Interprocess mutex not working / throwing exception when trying to write lock
by nav999 19 Oct '15

19 Oct '15

> Hi, > > 1. Your lockWithWriteLock and lockWithReadLock create a lock, which locks > on construction and unlocks on destruction, hence when the function > returns no lock is held on the mutex. > > 2. The fact that you put a scope here makes me think that your intention > is for the lock to be unlocked at the end of this scope (which it won't, > as it is unlocked way before, as per #1). > > { > std::cout<<"Program 1: Before first locking > -------------------------- 1 v\n"; > temp.sharedMutex->lockWithWriteLock(); > const unsigned int SLEEP_TIME_IN_SECOND = 60; > std::cout<<"Program 1: sleep for "<< SLEEP_TIME_IN_SECOND << "\n"; > sleep(SLEEP_TIME_IN_SECOND); > std::cout<<"Program 1: Finished sleeping\n"; > } > > In this case though, you would perform the wait in bold while still > holding the lock, and hence preventing the 2nd program from locking it. > Once out of the scope you destroy the object right away. > > NOTE: both the issue in #1 and #2 lead to your first program possibly > deleting the mutex before the 2nd program is done with it. Which leads to > the issue you are experiencing. > > 3. If you need to have the 1st program wait for the 2nd program to be > done, then do not use sleeps, use a condition_variable. Thanks. I didn't know the lock unlocks on destruction. I had taken a cue from a post on StackOverflow: http://stackoverflow.com/questions/12439099/interprocess-reader-writer-lock… I'm using sleep only for testing purpose. The dilemma still is, how to make the mutex visible to both processes? This thread got rejected by the admin who suggested it could be posted on the users subforum, so kindly reply to my post there to continue the discussion: http://boost.2283326.n4.nabble.com/interprocess-Interprocess-mutex-not-work… -- View this message in context: http://boost.2283326.n4.nabble.com/interprocess-Interprocess-mutex-not-work… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 1

[interprocess] How to know how much memory is taken up by an object allocated in boost interprocess shared memory?
by nav999 19 Oct '15

19 Oct '15

Re-posting, as the boost mailing list rejected the first post <http://boost.2283326.n4.nabble.com/How-to-know-how-much-memory-is-taken-up-…> mentioning that I had to add "[interprocess]" to the subject line. I have asked this question on stackoverflow <http://stackoverflow.com/questions/30642585/why-does-an-object-allocated-in…> , but got no response. For this program: #include <iostream> #include <boost/interprocess/mapped_region.hpp> #include <boost/interprocess/managed_shared_memory.hpp> #include <boost/interprocess/containers/list.hpp> #include <iostream> #define SHARED_MEMORY_NAME "SO12439099-MySharedMemory" #define DATAOUTPUT "OutputFromObject" #define INITIAL_MEM 650000 #define STATE_MATRIX_SIZE 4 using namespace std; namespace bip = boost::interprocess; class SharedObject { public: unsigned int tNumber; bool pRcvdFlag; bool sRcvdFlag; unsigned long lTimeStamp; }; typedef bip::allocator<SharedObject, bip::managed_shared_memory::segment_manager> ShmemAllocator; typedef bip::list<SharedObject, ShmemAllocator> SharedMemData; int main() { bip::managed_shared_memory* seg; SharedMemData *sharedMemOutputList; bip::shared_memory_object::remove(DATAOUTPUT); seg = new bip::managed_shared_memory(bip::create_only, DATAOUTPUT, INITIAL_MEM); const ShmemAllocator alloc_inst(seg->get_segment_manager()); sharedMemOutputList = seg->construct<SharedMemData>("TrackOutput")(alloc_inst); std::size_t beforeAllocation = seg->get_free_memory(); std::cout<<"\nBefore allocation = "<< beforeAllocation <<"\n"; SharedObject temp; sharedMemOutputList->push_back(temp); std::size_t afterAllocation = seg->get_free_memory(); std::cout<<"After allocation = "<< afterAllocation <<"\n"; std::cout<<"Difference = "<< beforeAllocation - afterAllocation <<"\n"; std::cout<<"Size of SharedObject = "<< sizeof(SharedObject) <<"\n"; std::cout<<"Size of SharedObject's temp instance = "<< sizeof(temp) <<"\n"; }//main The output is: Before allocation = 649680 After allocation = 649632 Difference = 48 Size of SharedObject = 16 Size of SharedObject's temp instance = 16 If the size of SharedObject and it's instance is 16 bytes, then how can the difference in allocation be 48? Even if padding had automatically been done, it's still too much to account for 3 times the size (for larger structures it goes to 1.33 times the size). Because of this, I'm unable to allocate and dynamically grow the shared memory reliably. If SharedObject contains a list which grows dynamically, that could add to the uncertainty of space allocation even more. How can these situations be safely handled? How can I know exactly how much of memory to allocate? -- View this message in context: http://boost.2283326.n4.nabble.com/interprocess-How-to-know-how-much-memory… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 4

Do you know of standard implementation of async() that blocks on the future-destructor?
by Vicente J. Botet Escriba 18 Oct '15

18 Oct '15

Hi, all is in the title. Best, Vicente

3 5

[Math] Help needed with FreeBSD failures
by John Maddock 18 Oct '15

18 Oct '15

Can anyone familiar with FreeBSD help me figure out what's causing a large number of runtime failures from Boost.Math, for example http://www.boost.org/development/tests/develop/developer/output/Flast-FreeB… Strangely gcc-5.1.0 is fine, but 4.8.5, 5.2.0 and 6.0 all fail. Many thanks in advance, John.

2 4

[serialization] Massive failures in develop?
by John Maddock 18 Oct '15

18 Oct '15

Local testing seems to have badly failed: http://www.boost.org/development/tests/develop/developer/serialization.html I've only looked at the msvc failures, and there's an issue in the iostream class destructor - which is to say after the archive classes have been destructed, the iostream class they were using is left in a non-sane state. Beyond that I haven't been able to get anything sensible out of the debugger (looks like memory corruption actually, but I can't be sure). Any ideas? Thanks, John.

2 6

[thread] Do we can a non backward compatible version with non-blocking futures?
by Vicente J. Botet Escriba 18 Oct '15

18 Oct '15

Hi, in Boost 1.58 I fixed some issues as the result of the async and future<T>:then() was not a blocking future as the documentation described. However the implementation is horrible and I suspect that it is subject to deadlocks. BTW, I added already some fixes on the develop branch. Sometime ago I started in a branch an implementation that don't use blocking futures [1]. Well the implementation is also horrible after making futures non-blocking, but less ;-) The problem is that now I have some issues with the executors :( Anyway, Gor has told me that with the blocking implementation he is unable to define await_suspend (using resumable functions) >It is just if .then returns a blocking future, I cannot subscribe a callback to .then in await_suspend. >await_suspend(f, cb) { > f.then(cb); >} &will block here preventing coroutine from suspending I don't know yet if he will reach to configure boost::future<T> on the non-blocking branch. My question is if the Boost community will accept (or even wants) a breaking change on a near release (when I would reach to fix the executors issues) including non-blocking futures instead of the current blocking futures. Best, Vicente [1] https://github.com/boostorg/thread/tree/feature/non_blocking_futures

3 13

[intrusive]: determine the hook type of intrusive::list<>?
by Oliver Kowalke 18 Oct '15

18 Oct '15

I'd like to determine the hook type of an intrusive container (intrusive::list): template< typename List > void do_link( List & lst) { static_assert(std::is_same< typename List::???, my_hook_type >::value); lst.push_back( * this); } In the documentation I didn't found a hint. Oliver

1 0

[regression] New runners for old compilers MSVC-7.1 and GCC 3.4
by Ion Gaztañaga 17 Oct '15

17 Oct '15

Hi, The last compiler update two years ago in Boost 1.55 left MSVC-7.1 and GCC 3.3 as two of the oldest supported compilers: http://www.boost.org/users/history/version_1_55_0.html I have no access to GCC 3.3 but managed to get a Mingw-based GCC 3.4. I will run regressions for for both mingw-GCC-3.4 and msvc-7.1 in master and develop branches in case anyone is interested. I plan to maintain support for them in Move, Intrusive, Container and Interprocess until we reach consensus on a new compiler update. Best, Ion

6 6

[python] Merging pull request #25
by Edward Diener 17 Oct '15

17 Oct '15

The PR is necessary so that user's of Python to not see a deprecated warning coming from the updated type_traits whenever they use Boost python. Would the maintainer of Boost Python please take a look at this simple PR so we can get this in the upcoming release. Thanks !

1 0

[Build] Specify compiler on the command line
by Louis Dionne 17 Oct '15

17 Oct '15

Hi, Still attempting to setup Boost.Build for Hana, I find myself unable to specify the compiler to be used by `b2` on the command line. The system compiler is then used by default, which does not work because I need to test on recent compilers. This can be handled by writing a project-config.jam file with the following in it: import feature ; if ! clang in [ feature.values <toolset> ] { using clang : : /path/to/clang ; } However, this is not very script-friendly, and I wonder whether there's a way to specify it on the command-line instead. Regards, Louis

4 6

[iterator][range] Synchronization on 'master'
by Edward Diener 16 Oct '15

16 Oct '15

I have pushed a number of changes to iterator from 'develop' to 'master' for the next release. A series of these changes on 'develop', by Marcel Raad, is an attempt to remove from 'iterator' the use of the deprecated headers 'boost/iterator.hpp' and 'boost/detail/iterator.hpp' in favor of using 'std::iterator' directly instead of 'boost::iterator' and 'std::iterator_traits' and 'std::distance' directly instead of 'boost::detail::iterator_traits' and 'boost::detail::distance'. Essentially these changes mean that any other library using 'iterator' classes would fail if they attempted to refer to 'boost::iterator', 'boost::detail::iterator_traits', or 'boost::detail::distance'. After I had pushed these changes to 'master' I noticed that it broke 'range' on 'master' and reverted these specific pushed commits on iterator 'master'. On 'develop' the 'range' library ( and possibly other libraries using 'iterator' ) had been changed so that it correctly used the 'std::iterator' terminology rather than the deprecated 'boost::iterator' terminology. If we are going to make this change to 'iterator' on 'master' it needs to be co-ordinated with the same set of changes for other libraries which now work with these changes on 'develop'. I noticed quite a few changes for 'range' on 'develop' which have not been pushed to 'master' for the upcoming release. I will assume that the maintainer of 'range' will want to push these changes to 'master' for the upcoming release so this is a heads up that the changes ( actually the last 'develop' commit for 'range' ) need to be co-ordinated with 'iterator' if it is done. Similarly if any other library depending on 'iterator' needs these changes on 'master' it needs to be co-ordinated with 'iterator'. I will NOT be re-pushing these changes on 'iterator' until this co-ordination is in place as I do not want to break 'master' in the interim. I am also fine with waiting until after this upcoming release to re-push these 'iterator' change to 'master' if that is what is desired by others, but any library currently depending on these changes in 'develop' must be aware of what the decision end up to be.

5 9

[serialization] Test runners being stopped
by Tom Kent 16 Oct '15

16 Oct '15

I think there is a bug in the serialization library that is breaking out of the test harness and causing window's error handling to kick in (when running on Windows, obviously). Usually when this happens the test runner application eventually (I believe) times out the test and marks it as failed. However, there are an incredible number of failures happening (since late last week) and they are bogging down the entire test run. Most of the runs I have attempted in the last week on windows have failed...the ones that have succeeded have taken ~12hrs up from the normal 3-4hrs. I was able to capture a stack trace of one of these random failures: msvcp140d.dll!00007ff9cfffb968() Unknown msvcp140d.dll!00007ff9cff73005() Unknown > test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::_Endwrite() Line 649 C++ test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::close() Line 341 C++ test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::~basic_filebuf<wchar_t,std::char_traits<wchar_t> >() Line 155 C++ test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::~basic_ofstream<wchar_t,std::char_traits<wchar_t> >() Line 1068 C++ test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::`vbase destructor'() C++ test_list_ptrs_text_warchive.exe!test_list() Line 65 C++ test_list_ptrs_text_warchive.exe!test_main(int __formal, char * * __formal) Line 176 C++ test_list_ptrs_text_warchive.exe!main(int argc, char * * argv) Line 203 C++ [External Code] I'd be happy to help get to the bottom of this, if you can give me any more diagnostic steps to take. We need to resolve this ASAP because it is preventing the windows test runners from producing timely results and we have a release coming up. Thanks, Tom

2 3

[test] BOOST_PP_VARIADICS is defined twice
by Andrey Semashev 16 Oct '15

16 Oct '15

Hi, For some reason Boost.Test defines the BOOST_PP_VARIADICS macro, which, I believe, is a macro defined by Boost.Preprocessor. This results in build errors as can be seen here: http://www.boost.org/development/tests/develop/developer/output/teeks99-01b… I think Boost.Test should not define BOOST_PP_VARIADICS and rely on Boost.PP for that. In any case, BOOST_PP* is not the namespace of Boost.Test.

2 4